Opened 13 years ago

Last modified 11 years ago

#31475 closed update

gnuradio: update to 3.5.0 — at Version 10

Reported by: axeljaeger@… Owned by: michaelld@…
Priority: Normal Milestone:
Component: ports Version: 2.0.3
Keywords: Cc: ryandesign@…
Port: gnuradio

Description (last modified by michaelld (Michael Dickens))

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

Change History (10)

comment:1 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: ryandesign@… added
Owner: changed from macports-tickets@… to michaelld@…
Summary: Update gnuradio to 3.4gnuradio: update to 3.4.1

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

comment:2 Changed 13 years ago by 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?

comment:3 Changed 13 years ago by 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.

comment:4 Changed 13 years ago by 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.

comment:5 in reply to:  4 Changed 13 years ago by 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.

comment:6 Changed 13 years ago by 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 :)

comment:7 in reply to:  6 Changed 13 years ago by 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.

comment:8 Changed 13 years ago by axeljaeger@…

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

comment:9 Changed 13 years ago by michaelld (Michael Dickens)

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

comment:10 Changed 12 years ago by michaelld (Michael Dickens)

Description: modified (diff)
Summary: gnuradio: update to 3.4.1gnuradio: update to 3.5.0

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.

Note: See TracTickets for help on using tickets.