Greetings,
New packages available in the Myriad-RF SDR Drivers PPA:
The packages are built for Ubuntu 12.04 Precise, 14.04 Trusty, 14.10 Utopic, 15.04 Vivid and 15.10 Wily for i386, amd64 and generic armhf architectures. In some cases, the same version of the driver is already available through the official Ubuntu channels, except for armhf.
More drivers (UHD, Umtrx) will be added soon where after we start populating the GNU Radio PPA.
Alex
That’s very cool indeed. Thanks, Alex!
Andrew
Adding to the myriad of drivers @ https://launchpad.net/~myriadrf/+archive/ubuntu/drivers/+packages
Many of my projects make use of CMake’s ProjectConfig Files. Think of these as an advanced replacement for package config when using CMake. Uploading for precise meant changing the minimum CMake version to 2.8.7 and changing find_package(Foo CONFIG) to find_package(Foo NO_MODULE). Seems arbitrary, but the NO_MODULE keyword seems to be supported in newer CMakes… so I can stick with that. Personally I cant wait for Ubuntu to retire 12.04 as its definitely feeling stale now.
I have added libosmodsp, gr-iqbal and gr-fcdproplus. I don’t think I have anything left that is worth adding.
It has become a bit weird with the version of gr-fcdproplus. For some reason, the debian package has version number 3.7.11, but this is no official version number. It is certainly a revision from before 0.1.0 was tagged. So now the official ubuntu package supersedes our package (which is newer).
Perhaps we can work around it by requesting version 0.1.0 when building gr-osmosdr?
That might work, I’m afraid of what’s going to happen when users install/upgrade and if packages are going to get messed up. If we are offering a newer version of gr-fcdproplus, then I think the only right way to handle this is to just have a newer version number.
It seems like the official ubuntu packages messed were inspired by the latest gnuradio version… so maybe its best to follow suit with the unofficial version numbers and use a partially made up version number like 10.0.1.0 and leave a message in the changelog about it.
It also crossed my mind that the gr-fcdproplus package could declare Replaces: gr-fcdproplus (>= 3.7) I’m just not clear how that will work since this is usually to replace older packages. To me the higher fake version number is the most bulletproof way to fix it, even if its technically wrong.
I was thinking that it might be time to give volk a separate package. Not this time around since everything is already built… but volk is now its own separate versioned git project, we should be able to give it its own debian package that gnuradio depends on. And we can set -DENABLE_INTERNAL_VOLK=OFF when building gnuradio. If a bug ever comes up, it will be easier to rebuild and patch libvolk. Its a relatively small project, we could even build it over in the drivers ppa just to have arm packages, if someone was interested in that.
Ok, I’m fine with the fake version numbers. It will be many days before I will be able to upload new packages so if you want to go on with gr-osmosdr you can just update the version numbers and rebuild.
[quote=“joshblum, post:6, topic:197, full:true”]
I was thinking that it might be time to give volk a separate package. Not this time around since everything is already built… but volk is now its own separate versioned git project, we should be able to give it its own debian package that gnuradio depends on.[/quote]
Let me know if this or anything else needs a repo under the Myriad-RF GitHub org.
Sounds like great progress overall! Now I just need to get Ubuntu up and running on my Novena… Any thoughts as to the best release to go for? And I’m assuming the Novena-RF driver will be going into the driver PPA(s)?
Cheers,
Andrew
Done with incrementing the gr-fcdproplus version number to 10.0.1.0
I guess that depends on whether you want to upgrade frequently or not. Non-LTS releases reach end of life within a year or so, while LTS releases receive updates for many years.
Looks like I needed to backport libosmosdr as well for the last two LTSs
I updated the wiki page to list the available software, versions, install commands:
http://wiki.myriadrf.org/Packaging
Looks like I can set the Architecture field to armhf so it only builds on the one architecture. So, yea, its probably a good time to debianize the novena driver, and to pick a good version number to tag it with. Dare I suggest 1.0? 
With that in mind, we will have to encourage Novena users to use Ubuntu in order to enjoy these novena rf PPAs.
1.0 seems reasonable! Keen to get Ubuntu up and running on my Novena all-in-one desktop. Got an SSD fitted and the RF module with panel mounted SMAs. Now just wondering which release to go for and how best to install, given there isn’t an installer and we’ll need to use the Novena Linux kernel.
I guess go with the latest linaro rootfs (this is ubuntu vivid):
http://releases.linaro.org/15.06/ubuntu/vivid-images/developer
There is no installer, but if you keep the boot partition in-tact, and copy over the linaro tarball in place of the old rootfs, and then copy over the kernel modules from the old rootfs: /lib/modules/(latest)… it should work.
As far as booting from the SSD… are there already instructions posted? I want to say that something will have to be recompiled: probably the device tree boot args ex: “root=/dev/mmcblk0p2” will have to change to the SSD device.
Thanks, I think overwriting a Debian rootfs with a Linaro one sounds like the simplest solution.
I did also ping Sean/xobs about this and he suggested pre-seeding the Ubuntu installer and pointed to:
Novena/Debian installer - Studio Kousagi Wiki
Else using deboostrap from a running Debian system.
Also noting that due to lack of 3D acceleration you’d need to swap out Unity for xfce4 or similar.
I did find this post regarding the boot args:
http://www.kosagi.com/forums/viewtopic.php?pid=132#p132
Regarding installing to SSD, last time I checked there was only an installer for wheezy, with a recovery image for jessie that you could use to debootstrap this.
Debian jessie bootstrap - Studio Kousagi Wiki
Just out of interest, how much effort do you think would be involved in packaging the Novena kernel for Ubuntu? Not sure if they ever plan to do this, given I’m not aware of any Ubuntu image or instructions.
It would be nice to see the kernel and the rf driver module (with dkms) in a proper package. I know there is a methodology to it, but I personally have no idea, I have always “manually” built my kernels.
Well, utopic has been phased out, and we cant even upload packages for it any more. I’m glad to be down to 4 OS versions 
Also, hackrf is now updated to 2015.07.02 tag, and the osmo* packages recompiled.
@csete was thinking that once gqrx is updated to use the new PPAs, maybe we should 1) add some links and or instructions to the wiki and 2) let a few of the relevant communities know that this exists 
I don’t know when I will make the switch because I have no idea how to do it without breaking everything for everybody…
Right now I’m working on a patch for gr-osmosdr adding RFSpace Cloud-IQ support. When the new gr-osmosdr is available I can perhaps update gqrx to require at least that version of gr-osmosdr, which will force an “upgrade” to the myriadrf packages. But I suspect this will lead to conflicts with the packages some people already have installed from the gqrx PPA.
Well, we are trying to have the latest packages available. It seems fitting to upgrade the gr-osmosdr package after the patches are merged. I think the biggest issue that people would see when upgrading gqrx if there is a switchover… is that the dependencies are not available. If a user simply runs apt-get update, then none of the gnuradio and drivers packages will be available until the new ppas are added to their system. They will get an error, and it wont be clear how to solve it.