# Bugs/Features Pybombs **URL:** \ **Category:** GNU Radio\ **Created:** [January 20, 2015, 7:06pm UTC](https://www.ruby-forum.com/t/bugs-features-pybombs/233893 "2015-01-20T19:06:12Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [January 20, 2015, 7:06pm UTC](https://www.ruby-forum.com/t/bugs-features-pybombs/233893/1 "2015-01-20T19:06:12Z")
Reporting what feel like two bugs in pybombs that only arise in CentOS. You won’t encounter these in Ubuntu. _1)_ Minor feature/bug: The config.defaults file does not contain rpm in the satisfy order list. It needs to be added manually. _2)_ Major bug: I’m calling this major because it prevents installation on CentOS and is very difficult to work through for newbies. When installing from source is the primary install option, the recipe files for pygobject and pygtk point to incorrect file locations. The rpms for CentOS 6.6 don’t contain these packages so install from source is the only option. _Current Pygobject_: [http://ftp.gnome.org/pub/GNOME/sources/pygobject/2.27/pygobject-2.27.91.patched.tar.gz](http://ftp.gnome.org/pub/GNOME/sources/pygobject/2.27/pygobject-2.27.91.patched.tar.gz) (this file does not exist at the specified ftp location any longer) _Should be:_ [http://ftp.gnome.org/pub/GNOME/sources/pygobject/2.27/pygobject-2.27.91.tar.gz](http://ftp.gnome.org/pub/GNOME/sources/pygobject/2.27/pygobject-2.27.91.tar.gz) Similar removal of “patched” modifier for the pygtk path. v/r, Rich ---
**Author:** ![reback](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b5ac83/32.png) [@reback](https://www.ruby-forum.com/u/reback)\ **Post date:** [January 27, 2015, 11:13pm UTC](https://www.ruby-forum.com/t/bugs-features-pybombs/233893/2 "2015-01-27T23:13:11Z")
On 01/20/2015 01:45 PM, Tom R. wrote: > This is a configuration option that you are asked when you first run > > And no, before you ask :), we cannot auto-detect this. I mean, we could > potentially auto-detect a few known Linux distros based on their layout or > a specific file in /etc or something, but as you’ve already seen with > something like CentOS, they tend to change things around quite a bit > between versions, so it’s something we’d have to constantly chase. And we > run the risk of incorrectly identifying other distros and doing the “wrong > thing.” There is a cross distro tool for this which seems to be supported very, very widely called “lsb\_release” zero@new-host-4 ~ % lsb\_release --help FSG lsb\_release v1.4 prints certain LSB (Linux Standard Base) and Distribution information. Usage: lsb\_release [OPTION]… With no OPTION specified it is the same as -v. Options: -v, --version Display the version of the LSB specification against which the distribution is compliant. -i, --id Display the string id of the distributor. -d, --description Display the single line text description of the distribution. -r, --release Display the release number of the distribution. -c, --codename Display the codename according to the distribution release. -a, --all Display all of the above information. -s, --short Display all of the above information in short output format. -h, --help Display this message. zero@new-host-4 ~ % lsb\_release -i Distributor ID: Gentoo zero@new-host-4 ~ % lsb\_release -a LSB Version: n/a Distributor ID: Gentoo Description: Gentoo Base System release 2.2 Release: 2.2 Codename: n/a -Zero ---
**Author:** ![reback](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b5ac83/32.png) [@reback](https://www.ruby-forum.com/u/reback)\ **Post date:** [January 20, 2015, 7:47pm UTC](https://www.ruby-forum.com/t/bugs-features-pybombs/233893/3 "2015-01-20T19:47:10Z")
On Tue, Jan 20, 2015 at 1:04 PM, Richard B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Reporting what feel like two bugs in pybombs that only arise in CentOS. > You won’t encounter these in Ubuntu. > > _1)_ Minor feature/bug: The config.defaults file does not contain rpm in > the satisfy order list. It needs to be added manually. This is a configuration option that you are asked when you first run pybombs. On an RPM based system, you should have already done this when you first run pybombs: Order in which to attempt installations when available, options are: src, rpm, deb satisfy\_order [deb,src]: It defaults to “deb,src” and you should change this to “rpm,src”. This is mentioned on the QuickStart guide: [http://gnuradio.org/redmine/projects/pybombs/wiki/QuickStart](http://gnuradio.org/redmine/projects/pybombs/wiki/QuickStart) And no, before you ask :), we cannot auto-detect this. I mean, we could potentially auto-detect a few known Linux distros based on their layout or a specific file in /etc or something, but as you’ve already seen with something like CentOS, they tend to change things around quite a bit between versions, so it’s something we’d have to constantly chase. And we run the risk of incorrectly identifying other distros and doing the “wrong thing.” > _Should be:_ > [http://ftp.gnome.org/pub/GNOME/sources/pygobject/2.27/pygobject-2.27.91.tar.gz](http://ftp.gnome.org/pub/GNOME/sources/pygobject/2.27/pygobject-2.27.91.tar.gz) > > Similar removal of “patched” modifier for the pygtk path. > > v/r, > Rich Sure. Again, though, this is something that we have to constantly chase between versions of different distros and how different projects set up their downloads. In this case, though, there’s no way around it. But that’s a) why we use the github pull request feature fairly readily to accept these kinds of patches: [http://gnuradio.org/redmine/projects/pybombs/wiki/Contributing](http://gnuradio.org/redmine/projects/pybombs/wiki/Contributing) b) the light-weight recipes (LWR) files are kept simple and straight-forward so they can be easily updated as these things so readily seem to change on us: [http://gnuradio.org/redmine/projects/pybombs/wiki/Using](http://gnuradio.org/redmine/projects/pybombs/wiki/Using) We definitely appreciate the feedback, though, and will have to see about updating the pygobject recipe. Can you provide us with a pull request for the working recipe that you have? Thanks! Tom