I’ve just tried to install the gnuradio debian packages in Ubuntu 9.10
(Karmic), as per the instructions in http://gnuradio.org/redmine/wiki/gnuradio/DebianPackages, and they don’t
work. The problem is that the packages depend on boost version = 1.37.0
(as opposed to >= 1.37.0) and Karmic ships with 1.38.0.
Is there any possibility of having this dependency fixed? I know that I
can build from source or even add “deb Index of /ubuntu/
jaunty main universe” to the sources.list and get the boost 1.37.0
packages, but it would be very nice to have a working Karmic package.
Cheers,
Pedro.
Pedro José Lobo Perea Tel: +34 913365521 / Fax: +34 913367801
Dpto. de Sistemas Electrónicos y de Control e-mail: [email protected]
E.U.I.T. Telecomunicación Universidad Politécnica de Madrid
Carretera de Valencia, km. 7 E-28031 Madrid - España / Spain
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
I’ve just tried to install the gnuradio debian packages in Ubuntu 9.10
(Karmic), as per the instructions in http://gnuradio.org/redmine/wiki/gnuradio/DebianPackages, and they don’t
work. The problem is that the packages depend on boost version = 1.37.0
(as opposed to >= 1.37.0) and Karmic ships with 1.38.0.
Is there any possibility of having this dependency fixed? I know that I
can build from source or even add “deb Index of /ubuntu/
jaunty main universe” to the sources.list and get the boost 1.37.0
packages, but it would be very nice to have a working Karmic package.
Unfortunately, the Boost ABI changes from release to release, so it is
not possible to build GNU Radio binary packages that are dependent on
a >= version of Boost. Rather, they have to be tied to a specific
Boost version.
Jaunty ships with 1.35 and 1.37 available. Karmic ships with 1.38 and
1.40 available. So it isn’t possible to build binary packages that
depend on a common version of Boost for both releases.
Right now I am testing the deb file creation process with 3.3git on
Karmic (9.10), using Boost 1.40, and these will get posted on gnuradio.org in the unstable repository. Depending on time (and
feedback), I will also build binary packages for 3.3git based on Boost
1.37, but it is unclear how to name them or publish them so as to not
conflict with the 9.10 ones.
Right now I am testing the deb file creation process with 3.3git on
Karmic (9.10), using Boost 1.40, and these will get posted on gnuradio.org in the unstable repository. Depending on time (and
feedback), I will also build binary packages for 3.3git based on Boost
1.37, but it is unclear how to name them or publish them so as to not
conflict with the 9.10 ones.
In the Ubuntu personal package archives it is common practice to
append “+distribution-name” after the package version,
see for example
I’m not sure if that would work if the same package is to be used for
Debian as well.
as you did for release 472 and 473 so we can eventually build the binary
deb packages by ourselves on ubuntu 9.04 or 9.10. Would it be possible
or is too difficult to make ?
as you did for release 472 and 473 so we can eventually build the binary deb
packages by ourselves on ubuntu 9.04 or 9.10. Would it be possible or is too
difficult to make ?
I had forgotten about this route. Yes, the 3.3git-594 version will be
posted as a source deb package, so you’ll be able to take it and
rebuild your own debs from it. You’ll simply need to edit
debian/control and replace boost 1.40 with boost 1.37 where indicated.
On Tue, Jan 19, 2010 at 15:31, Alexandru C. [email protected]
wrote:
In the Ubuntu personal package archives it is common practice to
append “+distribution-name” after the package version,
see for example Packages in “Gpredict releases” : Gpredict releases : “Gpredict Team” team
I’m not sure if that would work if the same package is to be used for
Debian as well.
Excellent idea. I’m actually on the road, so I won’t get to this
until Thursday when I return, but it certainly is the right way to
handle the two versions of the packages.
What is the reason you don’t follow usual Debian/Ubuntu layout
where you use distribution versions under dists/ instead of
package versions? Then it’s possible to build for multiple
distributions.
Also, why don’t you use Launchpad for hosting? It will build
automatically for multiple distro versions.
Are there plans to continue provide nightly builds for git versions?
On Wed, Jan 20, 2010 at 02:55, Johnathan C. [email protected] wrote:
On Sat, Jan 23, 2010 at 06:03, Alexander C. [email protected] wrote:
What is the reason you don’t follow usual Debian/Ubuntu layout
where you use distribution versions under dists/ instead of
package versions? Then it’s possible to build for multiple distributions.
It was mostly expedient at the time deb files were originally created.
The original plan was for something temporary until we could get the
packages into Debian and/or Ubuntu official repositories. While it
took longer than expected, 3.2.2 is in Debian unstable (“sid”) and
will soon get promoted to Debian testing (“squeeze”). Bdale Garbee is
the official package maintainer and he and I have been working
together to get things done. Hopefully Ubuntu will pick up 3.2.2 in
10.04 to replace the ancient 3.0.2 they have or had in their repo.
There still remains the hosting for the packages generated from our
current development. I plan (someday, grrr) to start using a more
automated system of uploading the packages to gnuradio.org, and then I
can shift to a more typical repository layout. Also, there are subtle
differences between debs for Debian vs. Ubuntu, and we haven’t planned
how to accommodate both in a single build infrastructure.
Also, why don’t you use Launchpad for hosting? It will build
automatically for multiple distro versions.
I’ve never really considered this; I’ll look into it.
Are there plans to continue provide nightly builds for git versions?
The only thing planned right now are periodic tarball generation at
points in development that relatively stable, such as the 3.3git-473
and 3.3git-594 tarballs.
On Mon, Jan 25, 2010 at 19:57, Johnathan C. [email protected] wrote:
took longer than expected, 3.2.2 is in Debian unstable (“sid”) and
will soon get promoted to Debian testing (“squeeze”). Â Bdale Garbee is
the official package maintainer and he and I have been working
together to get things done. Â Hopefully Ubuntu will pick up 3.2.2 in
10.04 to replace the ancient 3.0.2 they have or had in their repo.
That’s great news! Version on GnuRadio in Ubuntu/Debian was
a huge pain.
Speaking for the whole OpenBTS community - is it possible to release
3.2.3 with my patches, enabling runtime FPGA clock frequency setting?
They’re accepted into mainline, but it will take too long to get into
next
stable GnuRadio release and then to distros… Alternatively, they can
be applied as deb-patches to 3.2.2-1. This will be really, really
helpful,
as many in OpenBTS mailing list complain about long time to build
GnuRadio and get all its dependencies right. And without those patches
prebuilt GnuRadio is useless for OpenBTS users.
I’ve never really considered this; I’ll look into it.
You just need to change distro line in Changelog to trigger build for
different Ubuntu versions. That’s very easy to implement and you will
get automated build for all supported Ubuntu versions on all (three)
supported platforms.
On Tue, Jan 26, 2010 at 04:39, Alexander C. [email protected] wrote:
Speaking for the whole OpenBTS community - is it possible to release
3.2.3 with my patches, enabling runtime FPGA clock frequency setting?
They’re accepted into mainline, but it will take too long to get into next
stable GnuRadio release and then to distros… Alternatively, they can
be applied as deb-patches to 3.2.2-1. This will be really, really helpful,
as many in OpenBTS mailing list complain about long time to build
GnuRadio and get all its dependencies right. And without those patches
prebuilt GnuRadio is useless for OpenBTS users.
The next release official release of GNU Radio will be 3.3, not
3.2.x., as the API has changed. It will indeed take a while for this
to propagate through the Debian and Ubuntu release process.
However, it would be possible (as you mentioned) for Bdale to
cherry-pick the commits needed to implement the clock rate
configuration, and release the patched 3.2.2 into squeeze with this
very minor change. I’m not sure if he’s reading the list at the
moment, but I’ll contact him about it.
On Tue, Jan 26, 2010 at 05:38, Johnathan C. [email protected] wrote:
However, it would be possible (as you mentioned) for Bdale to
cherry-pick the commits needed to implement the clock rate
configuration, and release the patched 3.2.2 into squeeze with this
very minor change. I’m not sure if he’s reading the list at the
moment, but I’ll contact him about it.
FYI, the Debian/Ubuntu packaging is highly granular, and since OpenBTS
only uses the libusrp library and its dependencies, it is possible to
install only that package, without all the rest of the GNU Radio.
On Tue, Jan 26, 2010 at 16:41, Johnathan C. [email protected] wrote:
On Tue, Jan 26, 2010 at 05:38, Johnathan C. [email protected] wrote:
However, it would be possible (as you mentioned) for Bdale to
cherry-pick the commits needed to implement the clock rate
configuration, and release the patched 3.2.2 into squeeze with this
very minor change. Â I’m not sure if he’s reading the list at the
moment, but I’ll contact him about it.
Thank you! Feel free to contact me directly if you need any help
with identifying/applying those patches. I really want to get this
solved asap. This will allow us to package OpenBTS and thus make
it dumb stupid and fast to install. Instead of hours and effort required
now.
FYI, the Debian/Ubuntu packaging is highly granular, and since OpenBTS
only uses the libusrp library and its dependencies, it is possible to
install only that package, without all the rest of the GNU Radio.
Yes, I saw this and that’s neat. I prefer to install full GR, but many
will want just libusrp.
–
Regards,
Alexander C…
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.