@betaboon Does gqrx work for you with the soapy drivers? I did try several times over last year and could never get it to work.

@GrahamcOfBorg build gnuradio-with-packages gqrx

@bjornfor @the-kenny
How do you feel about upgrading from a stable version to a development version? The argument for upgrading would be that the latest stable is from 2014 and many new features have been implemented since then.

@markuskowa

@markuskowa: My personal opinion is that nixpkgs should only package released / stable upstream software. My thinking is that if a project, like osmosdr, has not produced a release in a long time, and the thinking is that users would benefit from getting the latest code, we should strive for making a release instead of working around it in nixpkgs. Think of other downstreams, if upstreams never release, all downstreams would eventually have to consider moving to unstable/unreleased code. And I think very few projects have a development process where all commits to git master branch are stable enough to be safely distributed to a wider user base.

The argument for upgrading would be that the latest stable is from 2014 and many new features have been implemented since then.

Then I would say that's a good argument for upstream to make a release :-)

@bjornfor I wrote an email to one of the developers a year ago, asking about a release, but did not get response. There is certainly a good argument to make a release, specially since the development branch seems to be pretty stable (works fine for me locally).

going through the mailing-list archive i found:

• http://lists.osmocom.org/pipermail/osmocom-sdr/2018-October/001847.html
• http://lists.osmocom.org/pipermail/osmocom-sdr/2018-June/001766.html

I just hopped into irc://freenode#osmocom just asking around

If I understand the mailing list right then there is no response for the request to make a new release? @betaboon did you get any response from the IRC?
@bjornfor debian uses ~90 patches to compensate for the old version 😲. Can you still call that v0.1.4? (maintaining that many patches sounds like a nightmare).
I understand the argument that we do not want to switch to unstable. Should we keep this PR open as "waiting-for-upstream" and hope that there will be a release soon or is there maybe some other middle ground solution?

@bjornfor debian uses ~90 patches to compensate for the old version

Wow.

I understand the argument that we do not want to switch to unstable. Should we keep this PR open as "waiting-for-upstream" and hope that there will be a release soon or is there maybe some other middle ground solution?

I don't know what middle ground would be. I see these options:

0. Kindly ask upstream again to make a release. Offer help.
1. Do a local distro-specific fork of the latest release (apparently how debian does it for this package).
2. Do a real fork the project, since upstreams that don't produce releases are effectively dead (IMHO).
3. Switch to unstable and update to arbitrary commits.

Since I'm not an active maintainer (just a guy that played with SDR some time ago) I'm not going to say hard no to option 3. (But you know I prefer option 0.)

@markuskowa i got told who in their IRC is the maintainer of gr-osmosdr (someone called horizon) but contacting that person didn't result in any kind of response.

here is the relevant excerpt of the chat:

[14:01:12] <betaboon> hello #osmocom, who or where would i contact about a new gr-osmosdr release, as the last release has been tagged in 2014 ?
[14:04:00] <neels> where = here is a good place. who: not sure, wait a bit and see what replies you get...
[14:04:46] <betaboon> neels: thanks for the headsup, I'll just idle here for a while :D
[14:13:11] <LaF0rge> betaboon: horizon is the person to talk to.
[14:13:52] <LaF0rge> betaboon: the osmocom-sdr@lists.osmocom.org mailing list is the right place for discussions about gr-osmosdr
[14:16:17] <betaboon> LaF0rge: thank you for the pointer to horizon 
[14:17:02] <betaboon> LaF0rge: regarding the mailing list: i found several attempts of discussions about the release issue on there all of which just ended unresolved
[14:17:15] <betaboon> eg: http://lists.osmocom.org/pipermail/osmocom-sdr/2018-June/001766.html
[14:18:43] <LaF0rge> betaboon: I'm sorry to hear it, but I guess there's not much to do othe than try to motivate the existing authors/maintainers :/
[14:20:10] <LaF0rge> betaboon: if the maintainer[s] loose interest, it may also be an option for somebody to step up - but then that person should at least be an existing developer who knows the codebase
[14:20:53] <betaboon> horizon: ^, any thoughts ?

Let's see if we get a response from the maintainers in the near future.
Option 1 and 2 would require that someone is willing to take on the task (this is beyond my personal scope). If there is no release coming, updating to unstable seems to be a reasonable compromise.

Could you also add libbladeRF dependency so that there would be no need for a separate PR?
Thank you.

@markuskowa it seems that other distros just use an unstable version.

@greydot Yes, Debian uses ~90 patches but still calls it v0.1.4. It is essentially an unstable version.
Does the latest bladerf support require osmosdr unstable? (there are a lot of bladerf related commits on the current master of osmosdr)

@markuskowa yes. v1.1.4 doesn't build with the latest libbladerf. The unstable code works just fine. See my closed PR linked above.

I'd say unstable should be preferred in that case. Releases are worthless if not happening regularly.

OK, it looks like the consensus is to go for the unstable version. We still have some to time to work out potential problems until 19.03.
@betaboon I wait for your reply to the libbladerf request.

I talked to someone called Hoernchen in irc://freenode#osmocom who is a longtime contributor to gr-osmosdr. he agreed that a release should be created (after i mentioned the debian-90+patch situation).
the gr-osmosdr maintainer called horizon(on irc) is thought to be quite active in irc, but went offline a couple of days ago and might be on vacation. i will keep an eye on him coming back online and keep pushing for a proper release.

For the time being I would be in favour of using a pinned commit in master.

@greydot @markuskowa regarding the libbladeRF support. i have no way of testing that it works as i dont own a bladerf.
currently soapybladedrf is included in soapysdr-with-plugins which is being used here. so bladerf might already work going the libbladerf->soapybladerf->soapysdr->gr-osmosdr route.

If that is not sufficient for you (or you prefer libbladerf->gr-osmosdr) i could add the dependency and test up to the point of having it compile. but as stated: i cannot test with a bladerf.

@betaboon I guess it is fine to add libbladerf. @greydot can test it (or already did test it in the other PR)?

@markuskowa I did test it successfully in the other PR with gqrx and osmocom_fft.

When can we expect this (plus bladerf support) merged?

@greydot I will merge it as soon as the changes mentioned above are made.

@markuskowa i just adapted your requested changes
@greydot i also added the libbladeRF dependency.

I can say that it still compiles and works with my limesdr-mini (tested in gnuradio-companion and gqrx)

@GrahamcOfBorg build gnuradio-with-packages
@GrahamcOfBorg build gqrx qradiolink

I've just built and tested gqrx with bladeRF from this branch. Seems to work just fine.

Thanks for all the effort!

you're welcome. thanks for the nice and quick interaction to get this done :)

hmm, awkward, mistyped my review script. Sorry