Forum: GNU Radio Release candidate 3.0.3rc1 available for testing

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Johnathan C. (Guest)
on 2007-02-21 19:29
(Received via mailing list)
All,

GNU Radio release candidate 3.0.3rc1 is available for testing:

http://gnuradio.org/releases/gnuradio/gnuradio-3.0...
http://gnuradio.org/releases/gnuradio/gr-howto-wri...

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
Trond D. (Guest)
on 2007-02-21 20:26
(Received via mailing list)
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
Johnathan C. (Guest)
on 2007-02-21 20:39
(Received via mailing list)
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
Eric B. (Guest)
on 2007-02-21 21:15
(Received via mailing list)
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
Michael D. (Guest)
on 2007-02-22 04:30
(Received via mailing list)
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.
Berndt Josef W. (Guest)
on 2007-02-22 06:14
(Received via mailing list)
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
Eric B. (Guest)
on 2007-02-22 06:16
(Received via mailing list)
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
Eric B. (Guest)
on 2007-02-22 06:45
(Received via mailing list)
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
Berndt Josef W. (Guest)
on 2007-02-22 13:59
(Received via mailing list)
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
Michael D. (Guest)
on 2007-02-22 15:49
(Received via mailing list)
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.
Johnathan C. (Guest)
on 2007-02-22 18:32
(Received via mailing list)
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
Michael D. (Guest)
on 2007-02-22 21:18
(Received via mailing list)
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
Johnathan C. (Guest)
on 2007-02-22 21:22
(Received via mailing list)
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
Eric B. (Guest)
on 2007-02-22 21:26
(Received via mailing list)
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
Eric B. (Guest)
on 2007-09-26 01:10
(Received via mailing list)
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
Johnathan C. (Guest)
on 2007-09-26 01:12
(Received via mailing list)
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
:-)

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
This topic is locked and can not be replied to.