GRC Command Not Found

Hello all,

I’ve used pybombs to install uhd+gnuradio on CentOS 6.6 x86_64.

I then executed ./pybombs env and sourced the generated file in my

After completely restarting my computer to make sure nothing funny was
going on, my terminal continues not to recognize gnuradio-companion as a
command. I can, however, run gnuradio-config-info. Some output that
be useful:

gnuradio-config-info -v: v3.7.6.1-41-g0bea2cce
gnuradio-config-info --builddate: Fri, 16 Jan 2015 00:18:57 (date/time
wrong here, not sure why)

What could cause this behavior? I’m not sure how to debug this.


On 01/16/2015 02:10 AM, Richard B. wrote:

gnuradio-config-info --builddate: Fri, 16 Jan 2015 00:18:57 (date/time
wrong here, not sure why)

What could cause this behavior? I’m not sure how to debug this.

Was GRC even built? Run “cmake …” from the GNU Radio build directory
(usually something like pybombs/src/gnuradio/build) and see if it’s
among the enabled components.


Thanks for that Martin. I enjoy learning things like this. What it shows
gnuradio-companion is disabled because it does not recognize pygtk

For whatever reason, the package-manager system on my centos 6.6 machine
has a broken link for pygobject and pygtk. I can’t depend on yum or
to install it for me.

I’ve downloaded pygobject from here:

I’ve downloaded pygtk from here:

I’ve been struggling for hours trying to get pygobject installed
so that pygtk recognizes it as being installed. Extracting pygobject to
pybombs/src/pygobject I run ./configure, make, sudo make install. No
arise and I see a new file create in my /usr/local/bin

When I then extract pygtk to pybombs/src/pygtk and run ./configure, I
receive the following partial output:

checking for GLIB - version >= 2.8.0… yes (version 2.28.8)
checking for PYGOBJECT… configure: error: Package requirements
(pygobject-2.0 >= 2.16.1) were not met:

No package ‘pygobject-2.0’ found

My path variable includes all the standard locations and I did not
the default install location of pygobject.

I’m at my wits end with this. Help would be greatly appreciated.

P.S. Is it possible to fix this error with a yum repo hack?

–2015-01-16 11:56:19–

Connecting to||:80… connected.
HTTP request sent, awaiting response… 302 Found
–2015-01-16 11:56:19–
Resolving…, 2001:6b0:e:2018::176
Connecting to||:80… connected.
HTTP request sent, awaiting response… 404 Not Found
2015-01-16 11:56:19 ERROR 404: Not Found.

The ftp link it’s using is correct, but for a filename error:


Should be

Removed patched from the tarball filename. I don’t know how pybombs
determines that link.


On Thu, Jan 15, 2015 at 11:44 PM, Martin B. [email protected]

Oh how I wish that was the fix, but sadly, no it’s not. My EPEL was
by default. I went so far as to enable EPEL-testing, but no change.


On Fri, Jan 16, 2015 at 12:49 PM, Marcus Müller
[email protected]

Is there someone who can explain the pybombs install mechanism to me. I
have been speaking to some CentOS guys about the package-manager and
say that pybombs isn’t using that at all because it is installing
from source.

If they are right, how does pybombs figure out where to go find programs
like pygobect and pygtk? I would like to manipulate this as a problem
if I can.


On Fri, Jan 16, 2015 at 1:17 PM, Richard B. [email protected]

Discuss-gnuradio mailing list
[email protected]

Hi John,

I believe I know what you’re referring to in the config file. But what
I’m interested in doing is changing the location of the source file
pybombs tries to download from, not just force the decision to install
from source.

Would you be able to explain how that is done?


Sent from my iPhone

In that case, you’d have to modify the respective LWR file in the
recipes/ folder. Most of it is pretty self-explanatory.

Please also note that the default installation preference order is
always deb, src; for CentOS, deb never works, so it really builds
everything from source. You should configure it to be rpm,src in 99% of


Hi Richard,
I’ve gotten rid of my CentOS 6.5 VM in favor of CentOS 7, where this was
not an issue.
However, usually “broken links” should not happen in CentOS.
Did you “yum clean all”, “yum check-updates” before installation? That
should make absolutely sure only the newest packet lists from the
official servers are used.
As a general reference for CentOS users: It often seems very helpful to
use the EPEL archives [1], which basically adds most of the packages
that are missing in RHEL, CentOS and Scientific Linux compared to

[1] Extra Packages for Enterprise Linux (EPEL) :: Fedora Docs

Thank you MarcusM, the LWR file was exactly what I needed. Very helpful.


On Sat, Jan 17, 2015 at 1:51 AM, Marcus Müller
[email protected]