Re: [Discuss-gnuradio] Release candidate 3.0.3rc1 available for testing
Haynes-Bent, Inc. wrote: > I am new to gnuradio and am trying to compile the project and keep > getting the same error you wrote about on the group: > > make[5]: Entering directory > `/home/ron/gnuradio/gnuradio-core/src/lib/general' > PYTHONPATH=../../../../gnuradio-core/src/python srcdir=. YTHON > ./generate_all.py > /bin/sh: YTHON: command not found > make[5]: *** [gr_add_cc.h] Error 127 > > I see your mistake in the E-Mail below but can not find where you > forgot the parenthesis around PYTHON. If you could point me in the > right direction it would be appreciated. It's already been fixed on the trunk and in the release branch. If you've updated but are still getting the above, you need to re-run bootstrap and configure to regenerate the Makefile. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release candidate 3.0.3rc1 available for testing
On Sat, Feb 24, 2007 at 04:00:25PM +1030, Berndt Josef Wulf wrote:
> G'day,
>
> I've successfully built and tested gnuradio-3.0.3rc1 with pkgsrc see below:
Glad to see that it's working.
> barossa: {376} make install
> ===> Checking for vulnerabilities in gnuradio-3.0.3rc1
> ===> Installing for gnuradio-3.0.3rc1
> => Automatic manual page handling
> => Registering installation for gnuradio-3.0.3rc1
> gnuradio-3.0.3rc1 requires installed package gnuradio-audio-jack-3.0.3rc1
> gnuradio-3.0.3rc1 requires installed package gnuradio-audio-oss-3.0.3rc1
> gnuradio-3.0.3rc1 requires installed package gnuradio-audio-portaudio-3.0.3rc1
> gnuradio-3.0.3rc1 requires installed package gnuradio-core-3.0.3rc1
> gnuradio-3.0.3rc1 requires installed package gnuradio-core-docs-3.0.3rc1
> gnuradio-3.0.3rc1 requires installed package gnuradio-examples-3.0.3rc1
> gnuradio-3.0.3rc1 requires installed package gnuradio-gsm-3.0.3rc1
> gnuradio-3.0.3rc1 requires installed package gnuradio-howto-3.0.3rc1
> gnuradio-3.0.3rc1 requires installed package gnuradio-radio-astronomy-3.0.3rc1
> gnuradio-3.0.3rc1 requires installed package gnuradio-trellis-3.0.3rc1
> gnuradio-3.0.3rc1 requires installed package gnuradio-usrp-3.0.3rc1
> gnuradio-3.0.3rc1 requires installed package gnuradio-video-sdl-3.0.3rc1
> gnuradio-3.0.3rc1 requires installed package gnuradio-wxgui-3.0.3rc1
> gnuradio-3.0.3rc1 requires installed package usrp-3.0.3rc1
> gnuradio-3.0.3rc1 requires installed package usrp-docs-3.0.3rc1
> barossa: {377}
>
> BTW: Is there any particular reason why gr-howto-write-a-block is standalone
> and not part of the gnuradio distribution? Seems odd
Yes. It's designed to illustrate how to build modules outside of the
main tree.
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release candidate 3.0.3rc1 available for testing
G'day,
I've successfully built and tested gnuradio-3.0.3rc1 with pkgsrc see below:
barossa: {376} make install
===> Checking for vulnerabilities in gnuradio-3.0.3rc1
===> Installing for gnuradio-3.0.3rc1
=> Automatic manual page handling
=> Registering installation for gnuradio-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-audio-jack-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-audio-oss-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-audio-portaudio-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-core-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-core-docs-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-examples-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-gsm-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-howto-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-radio-astronomy-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-trellis-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-usrp-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-video-sdl-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-wxgui-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package usrp-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package usrp-docs-3.0.3rc1
barossa: {377}
BTW: Is there any particular reason why gr-howto-write-a-block is standalone
and not part of the gnuradio distribution? Seems odd
cheerio Berndt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release candidate 3.0.3rc1 available for testing
Eric Blossom wrote: > Any chance there's a ' ' in any of the path names? I fixed this (well, since I was the one who broke it in the first place :-) I used $PYTHON instead of $(PYTHON). The $P evaluated to null and left YTHON. See my later email to you. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release candidate 3.0.3rc1 available for testing
On Thu, Feb 22, 2007 at 04:02:11PM -0500, Michael Dickens wrote: > Initially, for some unknown reason to me, with the 3.0 release I get > during "make": > > (cd .libs && rm -f libfilter-qa.la && ln -s ../libfilter-qa.la > libfilter-qa.la) > Making all in general > PYTHONPATH=../../../../gnuradio-core/src/python srcdir=. YTHON ./ > generate_all.py > /bin/sh: line 1: YTHON: command not found > > It looks like there is a typo in gnuradio-core/src/lib/general/ > Makefile* or Makefile.common .. but I don't have time right now to > look into this. I have to run now, but I'll check this out again > tonight. - MLD Any chance there's a ' ' in any of the path names? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release candidate 3.0.3rc1 available for testing
On Thu, Feb 22, 2007 at 02:17:30PM -0500, Michael Dickens wrote: > On Feb 22, 2007, at 11:30 AM, Johnathan Corgan wrote: > >please update to trunk revision 4588 and retest ticket:140. > >I'll need to do an equivalent fix in the release 3.0 branch if this > >works for you. > > Johnathan - Yes, that works; thank you. BTW> The change that you > made also renders the PATH in gr-usrp's run_tests.in redundant. > > Might it not be better instead for run_tests.in in gr-usrp to specify > the USRP libraries to include in the DYLD path instead of doing that > (for all modules) in the top-level run_tests.sh file? - since not all > modules rely upon the USRP but all do (for now) upon gnuradio-core? > I guess what I'm thinking of is to move all of the module-specific > stuff into each module, and leave the top-level run_tests to hold all > common stuff. These are not big or difficult changes, if you want me > to give it a go. - MLD I think you're right. I suspect that the change that mattered is only the DYLD_LIBRARY_PATH one. I'd like to go with the minimum fix. Otherwise, down the road it's hard to figure out which of the stuff added really needed to be there. Michael, can you give this a shot? Thanks, Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release candidate 3.0.3rc1 available for testing
Michael Dickens wrote: > Johnathan - Yes, that works; thank you. BTW> The change that you > made also renders the PATH in gr-usrp's run_tests.in redundant. Okay. > Might it not be better instead for run_tests.in in gr-usrp to specify > the USRP libraries to include in the DYLD path instead of doing that > (for all modules) in the top-level run_tests.sh file? - since not > all modules rely upon the USRP but all do (for now) upon > gnuradio-core? You're correct. It was a pre-morning-cup-of-coffee type of fix. I will make the change you recommend on the trunk in a few minutes so you can retest. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release candidate 3.0.3rc1 available for testing
On Feb 22, 2007, at 11:30 AM, Johnathan Corgan wrote: please update to trunk revision 4588 and retest ticket:140. I'll need to do an equivalent fix in the release 3.0 branch if this works for you. Johnathan - Yes, that works; thank you. BTW> The change that you made also renders the PATH in gr-usrp's run_tests.in redundant. Might it not be better instead for run_tests.in in gr-usrp to specify the USRP libraries to include in the DYLD path instead of doing that (for all modules) in the top-level run_tests.sh file? - since not all modules rely upon the USRP but all do (for now) upon gnuradio-core? I guess what I'm thinking of is to move all of the module-specific stuff into each module, and leave the top-level run_tests to hold all common stuff. These are not big or difficult changes, if you want me to give it a go. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release candidate 3.0.3rc1 available for testing
Eric Blossom wrote: > Johnathan or Michael, can you take a look at ticket:140. > I suspect that run_tests.sh is missing the usrp directory when it sets > DYLD_LIBRARY_PATH Michael--please update to trunk revision 4588 and retest ticket:140. I'll need to do an equivalent fix in the release 3.0 branch if this works for you. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release candidate 3.0.3rc1 available for testing
On Feb 21, 2007, at 11:19 PM, Eric Blossom wrote:
Johnathan or Michael, can you take a look at ticket:140.
I suspect that run_tests.sh is missing the usrp directory when it sets
DYLD_LIBRARY_PATH
I don't have much time today, but I'll try to take a look mid-day or
this evening when I have a free hour. Or not at all if Johnathan
gets there first.
I will also today try to run some tests on a PPC Mac, since I seem to
remember that it didn't work the last time I tried. GR does run fine
on an Intel-Mac, as I was working on one yesterday.
For the *Ports challenged, what's the difference between MacPorts and
DarwinPorts?
They're changing their name from DP to MP ... and going through a
rough transition in the process too. It used to be true that Fink
was almost always "behind" on the latest releases while DP was almost
always "on top of" them. During this transition, MP is having
trouble keeping up with the latest. I've posted patches for the
portfiles that are of use to me - those for GNU Radio and
OpenEmbedded - but even those take up to a week to propagate through
the system, and then sometimes things have changed again so the patch
is already out of date. I'm trying to get signed up to be a MP
developer, so-as to be able to have commit access for those portfiles
for GR and OE, but that also takes a long time.
Q?> For install systems such as DPKG or DP/MP, where should "gnuradio-
examples" be installed? Right now it's -not- installed ... so I was
thinking ${prefix}/share/gnuradio would make the most sense. I can
do this manually in DP/MP, as a "post-install" task.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release candidate 3.0.3rc1 available for testing
On Thursday 22 February 2007 15:18, Eric Blossom wrote: > On Thu, Feb 22, 2007 at 02:43:09PM +1030, Berndt Josef Wulf wrote: > > G'day, > > > > RC1 built fine, but I'm seeing a number of these errors during "gmake > > check". > > > > > > == > > ERROR: test_fff_002 (__main__.test_fft_filter) > > -- > > Traceback (most recent call last): > > File "./qa_fft_filter.py", line 191, in test_fff_002 > > self.fg.run() > > > > File > > "/usr/src/gnuradio/gnuradio-3.0.3rc1/gnuradio-core/src/python/gnuradio/gr > >/flow_graph.py", line 112, in run > > self.start () > > > > File > > "/usr/src/gnuradio/gnuradio-3.0.3rc1/gnuradio-core/src/python/gnuradio/gr > >/flow_graph.py", line 93, in start > > self.scheduler.start () > > > > File > > "/usr/src/gnuradio/gnuradio-3.0.3rc1/gnuradio-core/src/python/gnuradio/gr > >/scheduler.py", line 57, in start > > thread.start() > > > > File > > "/usr/src/gnuradio/gnuradio-3.0.3rc1/gnuradio-core/src/python/gnuradio/gr > >/gr_threading_24.py", line 420, in start > > _start_new_thread(self.__bootstrap, ()) > > error: can't start new thread > > Not sure about those... > Sounds like you are running out of some system resource. > > > another issue already highlighted by Greg Toxel is > > > > Testing gr_vmcircbuf_sysv_shm_factory... > > gr_vmcircbuf_sysv_shm: shmat (1): Too many open files > > gr_vmcircbuf_sysv_shm: shmget (1): Invalid argument > > ... gr_vmcircbuf_sysv_shm_factory: Doesn't work > > Testing gr_vmcircbuf_mmap_shm_open_factory... > > Those aren't (hard) failures. They just indicate that under stress > testing your shm* stuff won't work. Greg posted a note to the list a > while ago about how to bum p up the default number of shm segments > available. When shm* doesn't work, we use other techniques such as > shm_open or mmap'ing a tmp file. > > > Will install and test RC1 later tonight. > > Thanks, > Eric Greg's suggestion of bumping the values for shmmni and shmseg helped to solve the shmat(1) related matter. shmget(1) still fails with "invalid argument" when the second parameter of shmget evaluates to 8396800 - e.g. shmget(IPC_PRIVATE=0, size=8396800, pagesize=4096) No luck with thread related errors. It may be due to recent changes we had in the NetBSD source tree. Running the usual suspects from gnuradio-examples appear to be fine. cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release candidate 3.0.3rc1 available for testing
On Thu, Feb 22, 2007 at 02:43:09PM +1030, Berndt Josef Wulf wrote: > G'day, > > RC1 built fine, but I'm seeing a number of these errors during "gmake check". > > > == > ERROR: test_fff_002 (__main__.test_fft_filter) > -- > Traceback (most recent call last): > File "./qa_fft_filter.py", line 191, in test_fff_002 > self.fg.run() > > File > "/usr/src/gnuradio/gnuradio-3.0.3rc1/gnuradio-core/src/python/gnuradio/gr/flow_graph.py", > > line 112, in run > self.start () > > File > "/usr/src/gnuradio/gnuradio-3.0.3rc1/gnuradio-core/src/python/gnuradio/gr/flow_graph.py", > > line 93, in start > self.scheduler.start () > > File > "/usr/src/gnuradio/gnuradio-3.0.3rc1/gnuradio-core/src/python/gnuradio/gr/scheduler.py", > > line 57, in start > thread.start() > > File > "/usr/src/gnuradio/gnuradio-3.0.3rc1/gnuradio-core/src/python/gnuradio/gr/gr_threading_24.py", > > line 420, in start > _start_new_thread(self.__bootstrap, ()) > error: can't start new thread Not sure about those... Sounds like you are running out of some system resource. > another issue already highlighted by Greg Toxel is > > Testing gr_vmcircbuf_sysv_shm_factory... > gr_vmcircbuf_sysv_shm: shmat (1): Too many open files > gr_vmcircbuf_sysv_shm: shmget (1): Invalid argument > ... gr_vmcircbuf_sysv_shm_factory: Doesn't work > Testing gr_vmcircbuf_mmap_shm_open_factory... Those aren't (hard) failures. They just indicate that under stress testing your shm* stuff won't work. Greg posted a note to the list a while ago about how to bump up the default number of shm segments available. When shm* doesn't work, we use other techniques such as shm_open or mmap'ing a tmp file. > Will install and test RC1 later tonight. Thanks, Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release candidate 3.0.3rc1 available for testing
On Wed, Feb 21, 2007 at 09:29:44PM -0500, Michael Dickens wrote: > On OSX 10.4.8, both Intel and PPC Macs, 3.0.3rc1 does everything as > expected except "make check" as per ticket:140, including: > > configure > configure --prefix=FOO > make > make -j3 > > after "make install" (which puts the gr-usrp library where it expects > itself to be), the following also work: > > make check > make distcheck > > I have not tried these installed for functionality, but I would > assume they function as well as the SVN trunk. - MLD Johnathan or Michael, can you take a look at ticket:140. I suspect that run_tests.sh is missing the usrp directory when it sets DYLD_LIBRARY_PATH > ps> I'm close to having a MacPorts portfile available for GNU Radio, > which "does it all" ... but there's a current conflict between > wxWidgets and wxPython that is challenging to resolve. I'll let the > list know if/when I get this resolved ... until then I doubt that the > GR portfile will work for gr-wxgui. But if anyone (running OSX, > obviously) wants to try this out let me know & I'll send it on. > After some beta testing, I will submit it to the MacPorts project. Thanks for the update. For the *Ports challenged, what's the difference between MacPorts and DarwinPorts? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release candidate 3.0.3rc1 available for testing
G'day, RC1 built fine, but I'm seeing a number of these errors during "gmake check". == ERROR: test_fff_002 (__main__.test_fft_filter) -- Traceback (most recent call last): File "./qa_fft_filter.py", line 191, in test_fff_002 self.fg.run() File "/usr/src/gnuradio/gnuradio-3.0.3rc1/gnuradio-core/src/python/gnuradio/gr/flow_graph.py", line 112, in run self.start () File "/usr/src/gnuradio/gnuradio-3.0.3rc1/gnuradio-core/src/python/gnuradio/gr/flow_graph.py", line 93, in start self.scheduler.start () File "/usr/src/gnuradio/gnuradio-3.0.3rc1/gnuradio-core/src/python/gnuradio/gr/scheduler.py", line 57, in start thread.start() File "/usr/src/gnuradio/gnuradio-3.0.3rc1/gnuradio-core/src/python/gnuradio/gr/gr_threading_24.py", line 420, in start _start_new_thread(self.__bootstrap, ()) error: can't start new thread another issue already highlighted by Greg Toxel is Testing gr_vmcircbuf_sysv_shm_factory... gr_vmcircbuf_sysv_shm: shmat (1): Too many open files gr_vmcircbuf_sysv_shm: shmget (1): Invalid argument ... gr_vmcircbuf_sysv_shm_factory: Doesn't work Testing gr_vmcircbuf_mmap_shm_open_factory... Will install and test RC1 later tonight. cheerio Berndt On Thursday 22 February 2007 03:58, Johnathan Corgan wrote: > All, > > GNU Radio release candidate 3.0.3rc1 is available for testing: > > http://gnuradio.org/releases/gnuradio/gnuradio-3.0.3rc1.tar.gz > http://gnuradio.org/releases/gnuradio/gr-howto-write-a-block-3.0.3rc1.tar.g >z > > This is a bug fix and very minor enhancement release to the existing 3.0 > stable branch. All relevant issues that have been corrected on the main > development trunk have been back-ported. > > Details on the changes since release 3.0.2 are listed here: > > http://gnuradio.org/trac/wiki/Release3.0Branch > > Unfortunately, this release candidate does not include a fix for > ticket:39 (/lib vs /lib64 issues on Fedora Core 5 and 6). Those > developers who are affected by this issue and can perform testing of > potential fixes should contact Eric Blossom. > > As usual, please report any problems via the Trac ticket system, using > the 'guest' account with password 'gnuradio': > > http://gnuradio.org/trac/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release candidate 3.0.3rc1 available for testing
On OSX 10.4.8, both Intel and PPC Macs, 3.0.3rc1 does everything as expected except "make check" as per ticket:140, including: configure configure --prefix=FOO make make -j3 after "make install" (which puts the gr-usrp library where it expects itself to be), the following also work: make check make distcheck I have not tried these installed for functionality, but I would assume they function as well as the SVN trunk. - MLD ps> I'm close to having a MacPorts portfile available for GNU Radio, which "does it all" ... but there's a current conflict between wxWidgets and wxPython that is challenging to resolve. I'll let the list know if/when I get this resolved ... until then I doubt that the GR portfile will work for gr-wxgui. But if anyone (running OSX, obviously) wants to try this out let me know & I'll send it on. After some beta testing, I will submit it to the MacPorts project. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release candidate 3.0.3rc1 available for testing
On Wed, Feb 21, 2007 at 10:37:58AM -0800, Johnathan Corgan wrote: > Trond Danielsen wrote: > > > Is there a branch where a fix is being developed? > > I've created jcorgan/ticket-39 for this, but there are no fixes > checked-in yet. I've taken ownership of this ticket from Eric; I'll > follow up with you off-list. > Thanks, Johnathan! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release candidate 3.0.3rc1 available for testing
Trond Danielsen wrote: > Is there a branch where a fix is being developed? I've created jcorgan/ticket-39 for this, but there are no fixes checked-in yet. I've taken ownership of this ticket from Eric; I'll follow up with you off-list. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release candidate 3.0.3rc1 available for testing
2007/2/21, Johnathan Corgan <[EMAIL PROTECTED]>: Unfortunately, this release candidate does not include a fix for ticket:39 (/lib vs /lib64 issues on Fedora Core 5 and 6). Those developers who are affected by this issue and can perform testing of potential fixes should contact Eric Blossom. Is there a branch where a fix is being developed? -- Trond ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
