Release candidate 3.0.3rc1 available for testing


#1

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.gz

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 B…

As usual, please report any problems via the Trac ticket system, using
the ‘guest’ account with password ‘gnuradio’:

http://gnuradio.org/trac/


Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com


#2

2007/2/21, Johnathan C. removed_email_address@domain.invalid:

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 B…

Is there a branch where a fix is being developed?


Trond


#3

Trond D. 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 C.
Corgan Enterprises LLC
http://corganenterprises.com


#4

On Wed, Feb 21, 2007 at 10:37:58AM -0800, Johnathan C. wrote:

Trond D. 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


#5

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.


#6

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


#7

On Thu, Feb 22, 2007 at 02:43:09PM +1030, Berndt Josef W. wrote:

self.fg.run()

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


#8

On Wed, Feb 21, 2007 at 09:29:44PM -0500, Michael D. wrote:

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


#9

On Feb 21, 2007, at 11:19 PM, Eric B. 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.


#10

Eric B. 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 C.
Corgan Enterprises LLC
http://corganenterprises.com


#11

On Thursday 22 February 2007 15:18, Eric B. wrote:

Traceback (most recent call last):
/flow_graph.py", line 93, in start
_start_new_thread(self.__bootstrap, ())
… gr_vmcircbuf_sysv_shm_factory: Doesn’t work
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


#12

Michael D. 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 C.
Corgan Enterprises LLC
http://corganenterprises.com


#13

On Thu, Feb 22, 2007 at 02:17:30PM -0500, Michael D. wrote:

(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


#14

On Feb 22, 2007, at 11:30 AM, Johnathan C. 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


#15

Eric B. 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
:slight_smile:

I used $PYTHON instead of $(PYTHON). The $P evaluated to null and left
YTHON. See my later email to you.


Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com


#16

On Thu, Feb 22, 2007 at 04:02:11PM -0500, Michael D. wrote:

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