gnuradio: update to latest

[axeljaeger@…]

As a newer gnuradio is out than is provided by MacPorts (currently 3.6.2 versus 3.3.0), I wonder how hard it would be to upgrade the port to that?

[ryandesign (Ryan Carsten Schmidt)]

Looks like the livecheck will need to be adjusted as well, for the new location from which they're distributing the source.

​http://gnuradio.org/redmine/projects/gnuradio/wiki/Download

[michaelld (Michael Dickens)]

Yes, Yes. 3.4.1 was released just last week; it's on my long queue of things to do.

Question: Some of the gnuradio-* ports (which are still around) were removed from the 3.3.0 distro (e.g., gnuradio-mblock, which was part of 3.2.X). Given that we're now to 3.4.X, can I just remove those ports? Or, should I put a stub in place that just tells the user some relevant message but installs nothing?

[ryandesign (Ryan Carsten Schmidt)]

I wouldn't just delete them immediately, because users who already have them installed will thus keep them on their systems indefinitely, probably expecting them to still work and eventually be updated. The question is why are these ports no longer available upstream? Has their functionality been rolled into another port? If so, use replaced_by. Or is their functionality simply no longer available? That's trickier, but I'd probably make the port install only a readme file saying the software is gone; add notes to the port about this; and increase the revision to make this update available to users, so that they won't be left with obsolete software installed.

[michaelld (Michael Dickens)]

For better or worse, GNU Radio has an evolving set of APIs. 3.2 provided (I think) the largest number; 3.3 removed some and merged some into other places; 3.4 removes and merges some more; I expect 3.5 to . I generally like the direction the project is headed, but I also look forward to their APIs being a bit more stable. I think what I'll do, once I get there, is to leave the older stuff that wasn't merged -- I think they already have a note on them, so nothing is required on my part. Also they are not installed by the "gnuradio" meta-port; they have to be installed specifically. Anything that's been merged I'll make install a readme file & print out a message to the user to use the other port.

[ryandesign (Ryan Carsten Schmidt)]

Replying to michaelld@…:

Also they are not installed by the "gnuradio" meta-port; they have to be installed specifically.

Were they not installed by a previous version of the gnuradio meta-port?

If the APIs are removed, they probably don't work with the current version of gnuradio anymore, right? It might still be best to mark them as "replaced_by gnuradio" just to get them to be deactivated on user machines so they're not tempted to use them.

[michaelld (Michael Dickens)]

Yes, they were installed by previous versions of the meta-port. For example, gnuradio-mblock was installed by the 3.2 meta-port version, but was removed in 3.3 and hence isn't in that version. I think the various audio interfaces were merged in 3.4, so there will be just a "gnuradio-audio" instead of "gnuradio-audio-FOO"; might be the same for vocoders in 3.4 already, or they might be in the 3.5 release (I know they have already been merged in the master). For these (where they have been merged), I like your suggestion of using "replaced_by gnuradio-audio". For those that were removed, they do not work with the current GNU Radio master, but they should still work as stand-alone using the older version of GNU Radio -- though admittedly they might also conflict with more recent gnuradio-* ports (I haven't tried, and nobody has complained to the best of my knowledge). It might be time to just mark all the older ports as "replaced_by" and see if anyone complains :)

[ryandesign (Ryan Carsten Schmidt)]

Replying to michaelld@…:

they do not work with the current GNU Radio master, but they should still work as stand-alone using the older version of GNU Radio

I'd mark them all replaced_by gnuradio-something. If users want to install an older version of the gnuradio port using wiki:howto/InstallingOlderPort then they can install older versions of the relevant module ports the same way too.

[axeljaeger@…]

Any news on this? Yesterday I learned the hard way why GRC will not run without X11 :)

[michaelld (Michael Dickens)]

Working on it. Sorry for the delay; got lots in my queue.

[michaelld (Michael Dickens)]

3.5.0 was recently released. Hopefully "real soon now" I'll get around to putting up both UHD and the new GNU Radio -- which solely uses UHD for USRP-based transport (no more usrp, usrp2, gr-usrp etc). I've still got lots in my queue, but hopefully I'll find some time for this during the Holidays & also be able to test it on 10.6 and 10.7.

[nicholas.pate@…]

Cc Me!

[mars@…]

Still no news?

Unfortunately I am not able to use FunCube dongle without the update on Mac OS X, since 3.3 does not support 96kHz sampling frequency and FunCube block is not compatible with anything older than 3.4.

Also 3.5.1 has already been out for some time now..

I would compile it, but I failed so far in getting wx to cooperate with gnuradio on the 64bit 10.6.. so I am waiting for this update very eagerly.

[michaelld (Michael Dickens)]

I think the FunCube uses the built-in audio to get/send data, is that right? If so, then I think even 3.5.1 won't work with it yet. There's a branch of GNU Radio in my GR-dev area with a potential fix for the audio issue, but TTBOMK we've never had confirmation from anyone except me that it works. You can download ​the patch, or view ​my branch -- and, please do look at those & see if they work for you. If so, then please email the GR list to tell them so & see if we can get this branch committed.

On this ticket's front, I won't have time to address it for another month or so, just too much in my queue right now. I will get to it once my "had to be done yesterday" queue is executed. Also, in order to get 64-bit wx, you need to go with the wxWidgets-devel and py27-wxpython-devel ports; I'm actually trying them out this morning with GNU Radio from the GIT master. That said, I would advise you to go with the Qt interface if at all possible since it is faster, looks nicer, and is more robust overall.

[mars@…]

Well I failed compiling with Qt as well.. importing Qt.core in configure didn't work. I tried workarounding it, but I haven't been successful. The whole mess with different pythons for system and macports environment doesn't make me happy.

[michaelld (Michael Dickens)]

I really will get to this port soon. This is "Qt Upgrade Week", which might carry-over into next week. Then I have to deal with Octave and related ports. Then I'll work on GNU Radio and add UHD, switching to CMake from GNU Autotools, which should solve the Qt issue since CMake by default handles dependencies much more robustly than Autotools (at least in my experience). In the GNU Radio upgrade, I'll have to deprecate some older gnuradio-* ports, since they just don't play well with modern GNU Radio. So, I'm sorry but it'll be maybe another month; lots on my queue between MacPorts and life.

[martin.koskinen@…]

Cc Me!

[xieyanbo@…]

Cc Me!

[Feuermurmel (Michael Schwarz)]

Cc Me!

[jpantoga@…]

Cc Me!

[kpreid (Kevin Reid)]

Cc Me!

[michaelld (Michael Dickens)]

Fixed in r99885.

[hpux735 (William Dillon)]

Replying to michaelld@…:

Fixed in r99885.

Thanks for doing this!

I'm seeing a problem downloading the source tarball, however. I found it at this url: ​http://gnuradio.org/releases/gnuradio/gnuradio-3.6.2.tar.gz but the file doesn't exist at the mirrors checked by macports. For example, the mirror ​ftp://ftp.gnu.org/gnu/gnuradio/ only contains distributions up to and including version 3.3.0.

[michaelld (Michael Dickens)]

Thanks for pointing that out. I've added a change in r99935 that should do the trick. Do a selfupdate in a bit, and try again and please do report back.

[hpux735 (William Dillon)]

Replying to michaelld@…:

Thanks for pointing that out. I've added a change in r99935 that should do the trick. Do a selfupdate in a bit, and try again and please do report back.

Yep, that worked perfectly, thanks.

I've seemed to stumble on another problem that I can't figure out. Everything appears to build correctly, but when it's staging into the destroot, I get this error:

Error: org.macports.destroot for port gnuradio returned: error renaming "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gnuradio/gnuradio/work/destroot/opt/local/lib/python2.6/site-packages": no such file or directory

and it's true that the python2.6 director in lib doesn't exist.

[hpux735 (William Dillon)]

Cc Me!

[hpux735 (William Dillon)]

Cc Me!

[hpux735 (William Dillon)]

Cc Me!

[michaelld (Michael Dickens)]

I've added another change in r99947 which takes care of this issue for me. I'm also working (with my GNU Radio developer hat on) to add in a CMake hook for where to place Python scripts, so that I don't have to do this move manually. One little step at a time.

[hpux735 (William Dillon)]

Replying to michaelld@…:

I've added another change in r99947 which takes care of this issue for me. I'm also working (with my GNU Radio developer hat on) to add in a CMake hook for where to place Python scripts, so that I don't have to do this move manually. One little step at a time.

EXCELLENT! It now builds successfully. I'm getting minor errors with library paths, but that's likely something that the user needs to deal with, so I'll do some research on it. Thanks for taking this on!

[michaelld (Michael Dickens)]

I'm glad it's working for you! If you encounter another issue, please open a new ticket.