Packaging GNU Radio for Fedora

Hi,

I creating a spec file for GNU Radio, and I discovered some minor
issues:

  1. Standard library paths are hardcoded into some of the libraries. I
    use this command in the spec file to fix libtool before building:
    sed -i ‘s|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g’
    libtool
    sed -i ‘s|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g’ libtool

  2. Install path for some of the python modules are problematic:
    /usr/lib64/python2.4/site-packages/init.py
    /usr/lib64/python2.4/site-packages/_usrp_prims.la
    /usr/lib64/python2.4/site-packages/_usrp_prims.so
    /usr/lib64/python2.4/site-packages/usrp_dbid.py
    /usr/lib64/python2.4/site-packages/usrp_fpga_regs.py
    /usr/lib64/python2.4/site-packages/usrp_prims.py

Would it be possible to move these to a separate subfolder?

Cheers,

Trond D.

2007/3/6, Eric B. [email protected]:

Just out of curiosity, how does everybody else handle this problem?
I suspect that they’re not editing libtool source.

Please take a look at the .spec files for other applications built
with autotools.

I am aware of that this solution looks a bit dirty, but it is actually
taken from the packaging guidelines on the fedoraproject wiki:
http://fedoraproject.org/wiki/Packaging/Guidelines#head-a1dfb5f46bf4098841e31a75d833e6e1b3e72544

The message reported by rpmbuild is not an error; it is possible to
ignore it, but I wanted to do the right thing. Thats why I am asking.


Trond D.

On Tue, Mar 06, 2007 at 01:38:51PM +0100, Trond D. wrote:

Hi,

I creating a spec file for GNU Radio, and I discovered some minor issues:

  1. Standard library paths are hardcoded into some of the libraries. I
    use this command in the spec file to fix libtool before building:
    sed -i ‘s|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g’
    libtool
    sed -i ‘s|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g’ libtool

Just out of curiosity, how does everybody else handle this problem?
I suspect that they’re not editing libtool source.

Please take a look at the .spec files for other applications built
with autotools.

  1. Install path for some of the python modules are problematic:
    /usr/lib64/python2.4/site-packages/init.py
    /usr/lib64/python2.4/site-packages/_usrp_prims.la
    /usr/lib64/python2.4/site-packages/_usrp_prims.so
    /usr/lib64/python2.4/site-packages/usrp_dbid.py
    /usr/lib64/python2.4/site-packages/usrp_fpga_regs.py
    /usr/lib64/python2.4/site-packages/usrp_prims.py

Would it be possible to move these to a separate subfolder?

Yes, I’ll move the installation of those. It’ll be later today.

Eric

On Tue, Mar 06, 2007 at 01:38:51PM +0100, Trond D. wrote:

Would it be possible to move these to a separate subfolder?

Cheers,

Trond D.

In [4728] on the trunk, I moved these to site-packages/usrpm.

This change could impact user code that’s not in the tree.
In particular, any occurrences of any of:

import usrp_dbid
import usrp_prims
from usrp_fpga_regs import *

should be changed to:

from usrpm import usrp_dbid
from usrpm import usrp_prims
from usrpm.usrp_fpga_regs import *

respectively.

Sorry about the incompatible change, but this does clean up our
installation.

Thanks,
Eric

On Tue, Mar 06, 2007 at 05:42:34PM +0100, Trond D. wrote:

sed -i ‘s|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g’ libtool

Just out of curiosity, how does everybody else handle this problem?
I suspect that they’re not editing libtool source.

Please take a look at the .spec files for other applications built
with autotools.

I am aware of that this solution looks a bit dirty, but it is actually
taken from the packaging guidelines on the fedoraproject wiki:
http://fedoraproject.org/wiki/Packaging/Guidelines#head-a1dfb5f46bf4098841e31a75d833e6e1b3e72544

Very good. I guess they don’t care for --rpath :wink:

The message reported by rpmbuild is not an error; it is possible to
ignore it, but I wanted to do the right thing. Thats why I am asking.

Thanks for you efforts on this. It’ll be great to have an rpm.

Trond D.

Eric

In [4728] on the trunk, I moved these to site-packages/usrpm.

Why usrpm? Why not just usrp?

Matt

On Tue, Mar 06, 2007 at 07:39:45PM -0800, Matt E. wrote:

In [4728] on the trunk, I moved these to site-packages/usrpm.

Why usrpm? Why not just usrp?

Matt

Short answer: because it doesn’t work.

Long answer: because there’s lots of code that does

from gnuradio import usrp

which of course puts a module called usrp in the namespace.
If you then try

from usrp import usrp_dbid

  or

import usrp.usrp_dbid

You’re hosed :wink:

Lacking any creativity, I called it usrpm for “usrp module”

Eric

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs