#31475: gnuradio: update to 3.4.1 ---------------------------------------+------------------------------------ Reporter: axeljaeger@… | Owner: michaelld@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Keywords: | Port: gnuradio ---------------------------------------+------------------------------------ Comment(by michaelld@…): 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? -- Ticket URL: <https://trac.macports.org/ticket/31475#comment:2> MacPorts <http://www.macports.org/> Ports system for Mac OS

#31475: gnuradio: update to 3.4.1 ---------------------------------------+------------------------------------ Reporter: axeljaeger@… | Owner: michaelld@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Keywords: | Port: gnuradio ---------------------------------------+------------------------------------ Comment(by michaelld@…): 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. -- Ticket URL: <https://trac.macports.org/ticket/31475#comment:4> MacPorts <http://www.macports.org/> Ports system for Mac OS

#31475: gnuradio: update to 3.4.1 ---------------------------------------+------------------------------------ Reporter: axeljaeger@… | Owner: michaelld@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Keywords: | Port: gnuradio ---------------------------------------+------------------------------------ Comment(by michaelld@…): 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 :) -- Ticket URL: <https://trac.macports.org/ticket/31475#comment:6> MacPorts <http://www.macports.org/> Ports system for Mac OS

#31475: gnuradio: update to 3.4.1 ---------------------------------------+------------------------------------ Reporter: axeljaeger@… | Owner: michaelld@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Keywords: | Port: gnuradio ---------------------------------------+------------------------------------ Comment(by axeljaeger@…): Any news on this? Yesterday I learned the hard way why GRC will not run without X11 :) -- Ticket URL: <https://trac.macports.org/ticket/31475#comment:8> MacPorts <http://www.macports.org/> Ports system for Mac OS

#31475: gnuradio: update to 3.5.0 ---------------------------------------+------------------------------------ Reporter: axeljaeger@… | Owner: michaelld@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Keywords: | Port: gnuradio ---------------------------------------+------------------------------------ Old description:

As gnuradio 3.4.1 is out, I wonder how hard it would be to upgrade the port to that?

New description: As [a newer] gnuradio [] is out, I wonder how hard it would be to upgrade the port to that? -- Comment(by michaelld@…): 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. -- Ticket URL: <https://trac.macports.org/ticket/31475#comment:10> MacPorts <http://www.macports.org/> Ports system for Mac OS

#31475: gnuradio: update to latest ---------------------------------------+------------------------------------ Reporter: axeljaeger@… | Owner: michaelld@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Keywords: | Port: gnuradio ---------------------------------------+------------------------------------ Old description:

As [a newer] gnuradio [] is out, I wonder how hard it would be to upgrade the port to that?

New description: As a newer gnuradio is out than is provided by MacPorts (currently 3.5.1 versus 3.3.0), I wonder how hard it would be to upgrade the port to that? -- Comment(by michaelld@…): 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 [http://lists.gnu.org/archive/html/patch- gnuradio/2011-11/msg00000.html the patch], or view [http://gnuradio.org/cgit/michaelld.git/log/?h=osx_source_fix 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. -- Ticket URL: <https://trac.macports.org/ticket/31475#comment:13> MacPorts <http://www.macports.org/> Ports system for Mac OS

#31475: gnuradio: update to latest ---------------------------------------+------------------------------------ Reporter: axeljaeger@… | Owner: michaelld@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Keywords: | Port: gnuradio ---------------------------------------+------------------------------------ Old description:

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

New description: 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? -- Comment(by michaelld@…): 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. -- Ticket URL: <https://trac.macports.org/ticket/31475#comment:15> MacPorts <http://www.macports.org/> Ports system for Mac OS

#31475: gnuradio: update to latest ---------------------------+------------------------- Reporter: axeljaeger@… | Owner: michaelld@… Type: update | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Resolution: fixed | Keywords: Port: gnuradio | ---------------------------+------------------------- Comment (by hpux735@…): Replying to [comment:21 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. -- Ticket URL: <https://trac.macports.org/ticket/31475#comment:22> MacPorts <http://www.macports.org/> Ports system for Mac OS

#31475: gnuradio: update to latest ---------------------------+------------------------- Reporter: axeljaeger@… | Owner: michaelld@… Type: update | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Resolution: fixed | Keywords: Port: gnuradio | ---------------------------+------------------------- Comment (by hpux735@…): Replying to [comment:23 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. -- Ticket URL: <https://trac.macports.org/ticket/31475#comment:24> MacPorts <http://www.macports.org/> Ports system for Mac OS

#31475: gnuradio: update to latest ---------------------------+------------------------- Reporter: axeljaeger@… | Owner: michaelld@… Type: update | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Resolution: fixed | Keywords: Port: gnuradio | ---------------------------+------------------------- Comment (by hpux735@…): Replying to [comment:28 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! -- Ticket URL: <https://trac.macports.org/ticket/31475#comment:29> MacPorts <http://www.macports.org/> Ports system for Mac OS