Forum: GNU Radio build error with "next" branch

Hi,

Kubuntu 12.04 32bit LTS, latest gnuradio "master", everything works. Now 
I
thought, give "next" a try, but this fails. Before I go into details and
search for the exact error, I followed this procedure mentioned below. 
Is
this the correct way, or is this already part of the problem? :)

"git checkout next" and "git pull" in the gnuradio folder, "cd build", 
"make
clean", "cmake ../", "make". Then I run into an error, relative early. I
will extract it when it is confirmed that my procedure was OK, as this 
is
another PC and I will have to transfer it first. I know that exact error
messages are important, don't worry.

The way back with "git checkout master", otherwise identical to the 
above
mentioned procedure, works just fine.

Thank you, and with best regards

Ralph.



--

Ralph A. Schmid
Mondstr. 10
90762 Frth
+49-171-3631223
ralph@schmid.xxx
http://www.bclog.de/

On Wed, Feb 20, 2013 at 7:54 AM, Ralph A. Schmid, dk5ras
<ralph@schmid.xxx>wrote:

> will extract it when it is confirmed that my procedure was OK, as this is
> another PC and I will have to transfer it first. I know that exact error
> messages are important, don't worry.
>
> The way back with "git checkout master", otherwise identical to the above
> mentioned procedure, works just fine.
>
> Thank you, and with best regards
>
> Ralph.
>

Yes, that's the way to do it.

Tom

OK, below the output.

"Master" runs just fine through the whole process and runs, so I assume 
the
system should be OK so far. The only non standard stuff on the system is 
a
minimum gnuradio 3.4.2 installation for OpenBTS, some command line tools 
that
somehow depend on UHD and RTLSDR and maybe gnuradio...

Ralph.

[  2%] Generating documentation with doxygen
/home/ras/gnuradio/gr-audio/lib/osx/osx_impl.h:57: Warning: include file
boost/detail/endian.hpp not found, perhaps you forgot to add its 
directory to
INCLUDE_PATH?
/home/ras/gnuradio/gruel/src/lib/pmt/pmt_int.h:243: Warning: include 
file
pmt_unv_int.h not found, perhaps you forgot to add its directory to
INCLUDE_PATH?
This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian)
entering extended mode
(./_formulas.tex
LaTeX2e <2009/09/24>
Babel <v3.8l> and hyphenation patterns for english, usenglishmax, 
dumylang,
noh
yphenation, loaded.
(/usr/share/texmf-texlive/tex/latex/base/article.cls
Document Class: article 2007/10/19 v1.4h Standard LaTeX document class
(/usr/share/texmf-texlive/tex/latex/base/size10.clo))
(/usr/share/texmf-texlive/tex/latex/graphics/epsfig.sty
(/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty
(/usr/share/texmf-texlive/tex/latex/graphics/keyval.sty)
(/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty
(/usr/share/texmf-texlive/tex/latex/graphics/trig.sty)
(/etc/texmf/tex/latex/config/graphics.cfg)
(/usr/share/texmf-texlive/tex/latex/graphics/dvips.def))))
No file _formulas.aux.
[1] [2] [3] [4] [5] (./_formulas.aux) )
Output written on _formulas.dvi (5 pages, 1272 bytes).
Transcript written on _formulas.log.
[  2%] Built target doxygen_target
[  2%] Generating ../include/gruel/pmt_serial_tags.h
[  2%] Generating pmt/pmt_unv_int.h, pmt/qa_pmt_unv.h, pmt/pmt_unv.cc,
pmt/qa_pmt_unv.cc
Scanning dependencies of target gruel
[  2%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_accepter.cc.o
[  2%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_accepter_msgq.cc.o
[  2%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_producer.cc.o
[  3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_queue.cc.o
[  3%] Building CXX object 
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_unv.cc.o
[  3%] Building CXX object 
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt.cc.o
[  3%] Building CXX object 
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_io.cc.o
[  3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_pool.cc.o
[  3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_serialize.cc.o
[  3%] Building CXX object 
gruel/src/lib/CMakeFiles/gruel.dir/realtime.cc.o
[  3%] Building CXX object 
gruel/src/lib/CMakeFiles/gruel.dir/sys_pri.cc.o
[  3%] Building CXX object 
gruel/src/lib/CMakeFiles/gruel.dir/thread.cc.o
[  3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/thread_body_wrapper.cc.o
[  3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/thread_group.cc.o
Linking CXX shared library libgruel-3.7git.so
make[2]: *** [gruel/src/lib/libgruel-3.7git.so.0.0.0] Error 1
make[1]: *** [gruel/src/lib/CMakeFiles/gruel.dir/all] Error 2
make: *** [all] Error 2

On Wed, Feb 20, 2013 at 9:19 AM, Ralph A. Schmid <ralph@schmid.xxx> 
wrote:

>
> to INCLUDE_PATH?
>
>
> (/usr/share/texmf-texlive/tex/latex/graphics/trig.sty)
>
>
> gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_queue.cc.o
> gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_pool.cc.o
> [ 3%] Building CXX object
>
> make: *** [all] Error 2
>

Ralph,

Are you sure this is the entire output? There's nothing indicating what 
the
error was.

Still, I'm wondering if there's a problem with it pulling in installed
versions of the headers as opposed to local versions (we worked to 
correct
this from happening fairly recently, but doesn't mean it's not still
happening here).

Tom

Hi,



I did not copy everything from beginning on, as it looked all normal, 
but if
it helps I can copy all the stuff, including output of cmake - as the 
thing
happens in an earliy stage it is not so much stuff to look through...
Although I do not know very much about linux, I do not fear any special
instructions you may give me, to get more information about it.



I assume completely deleting the "build" folder contents before 
switching
the branch should not make a difference?!



Ralph.



From: trondeau@trondeau.com [mailto:trondeau@trondeau.com] On Behalf Of 
Tom
Rondeau
Sent: Wednesday, February 20, 2013 3:25 PM
To: Ralph A. Schmid
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] build error with "next" branch



On Wed, Feb 20, 2013 at 9:19 AM, Ralph A. Schmid <ralph@schmid.xxx> 
wrote:

OK, below the output.



"Master" runs just fine through the whole process and runs, so I assume 
the
system should be OK so far. The only non standard stuff on the system is 
a
minimum gnuradio 3.4.2 installation for OpenBTS, some command line tools
that somehow depend on UHD and RTLSDR and maybe gnuradio...



Ralph.



[ 2%] Generating documentation with doxygen

/home/ras/gnuradio/gr-audio/lib/osx/osx_impl.h:57: Warning: include file
boost/detail/endian.hpp not found, perhaps you forgot to add its 
directory
to INCLUDE_PATH?

/home/ras/gnuradio/gruel/src/lib/pmt/pmt_int.h:243: Warning: include 
file
pmt_unv_int.h not found, perhaps you forgot to add its directory to
INCLUDE_PATH?

This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian)

entering extended mode

(./_formulas.tex

LaTeX2e <2009/09/24>

Babel <v3.8l> and hyphenation patterns for english, usenglishmax, 
dumylang,
noh

yphenation, loaded.

(/usr/share/texmf-texlive/tex/latex/base/article.cls

Document Class: article 2007/10/19 v1.4h Standard LaTeX document class

(/usr/share/texmf-texlive/tex/latex/base/size10.clo))

(/usr/share/texmf-texlive/tex/latex/graphics/epsfig.sty

(/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty

(/usr/share/texmf-texlive/tex/latex/graphics/keyval.sty)

(/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty

(/usr/share/texmf-texlive/tex/latex/graphics/trig.sty)

(/etc/texmf/tex/latex/config/graphics.cfg)

(/usr/share/texmf-texlive/tex/latex/graphics/dvips.def))))

No file _formulas.aux.

[1] [2] [3] [4] [5] (./_formulas.aux) )

Output written on _formulas.dvi (5 pages, 1272 bytes).

Transcript written on _formulas.log.

[ 2%] Built target doxygen_target

[ 2%] Generating ../include/gruel/pmt_serial_tags.h

[ 2%] Generating pmt/pmt_unv_int.h, pmt/qa_pmt_unv.h, pmt/pmt_unv.cc,
pmt/qa_pmt_unv.cc

Scanning dependencies of target gruel

[ 2%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_accepter.cc.o

[ 2%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_accepter_msgq.cc.o

[ 2%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_producer.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_queue.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_unv.cc.o

[ 3%] Building CXX object 
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt.cc.o

[ 3%] Building CXX object 
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_io.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_pool.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_serialize.cc.o

[ 3%] Building CXX object 
gruel/src/lib/CMakeFiles/gruel.dir/realtime.cc.o

[ 3%] Building CXX object 
gruel/src/lib/CMakeFiles/gruel.dir/sys_pri.cc.o

[ 3%] Building CXX object gruel/src/lib/CMakeFiles/gruel.dir/thread.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/thread_body_wrapper.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/thread_group.cc.o

Linking CXX shared library libgruel-3.7git.so

make[2]: *** [gruel/src/lib/libgruel-3.7git.so.0.0.0] Error 1

make[1]: *** [gruel/src/lib/CMakeFiles/gruel.dir/all] Error 2

make: *** [all] Error 2



Ralph,



Are you sure this is the entire output? There's nothing indicating what 
the
error was.



Still, I'm wondering if there's a problem with it pulling in installed
versions of the headers as opposed to local versions (we worked to 
correct
this from happening fairly recently, but doesn't mean it's not still
happening here).



Tom

On Wed, Feb 20, 2013 at 9:49 AM, Ralph A. Schmid, dk5ras
<ralph@schmid.xxx>wrote:

> ** **
>
> I assume completely deleting the build folder contents before switching
> the branch should not make a difference?!****
>
> ** **
>
> Ralph.
>

Actually, yes, delete the build directory. There's possibly some stuff
that's built there that's confusing things. Cmake should automatically 
tell
that things are old and need to be regenerated, but just to be safe. (I
actually have entirely separate build folders for each branch to make 
sure
thing stay sane.)

Also, probably no need for the entire output. I'm just trying to figure 
out
what the real error message is. Just look through the output and see 
where
it gives you any errors. Don't worry about Doxygen errors. And I know 
you
said you were new to Linux, so treat this as a learning exercise.
Understanding how to grok your compiler output is a really useful skill 
:)

Tom

On Wed, Feb 20, 2013 at 7:30 AM, Tom Rondeau <tom@trondeau.com> wrote:

> On Wed, Feb 20, 2013 at 9:49 AM, Ralph A. Schmid, dk5ras <ralph@schmid.xxx
> > wrote:
>
> Actually, yes, delete the build directory. There's possibly some stuff
> that's built there that's confusing things. Cmake should automatically tell
> that things are old and need to be regenerated, but just to be safe. (I
> actually have entirely separate build folders for each branch to make sure
> thing stay sane.)
>

It's too late now, as the OP already did a git checkout and pull, but 
best
practice is to go into the build directory and do a 'sudo make 
uninstall'
to remove any traces of the first build that had gotten installed.  Then
delete the build directory, go back to the source directory, do the git
checkout and update to switch branches, and start over with a new  build
directory.

Johnathan

Yep, the output was complete, just copy and paste, and before it 
everything
looked normal. Now I emptied the build folder before starting over once
again - and, tadaaaa! I came over the magic 3%, at the moment it is at 
14%
without error. We will see if it completes, on my Core 2 Duo ThinkPad at 
1.6
GHz compiling takes a while...



Ralph.



From: trondeau@trondeau.com [mailto:trondeau@trondeau.com] On Behalf Of 
Tom
Rondeau
Sent: Wednesday, February 20, 2013 4:31 PM
To: Ralph A. Schmid, dk5ras
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] build error with "next" branch



On Wed, Feb 20, 2013 at 9:49 AM, Ralph A. Schmid, dk5ras 
<ralph@schmid.xxx>
wrote:

Hi,



I did not copy everything from beginning on, as it looked all normal, 
but if
it helps I can copy all the stuff, including output of cmake - as the 
thing
happens in an earliy stage it is not so much stuff to look through...
Although I do not know very much about linux, I do not fear any special
instructions you may give me, to get more information about it.



I assume completely deleting the "build" folder contents before 
switching
the branch should not make a difference?!



Ralph.



Actually, yes, delete the build directory. There's possibly some stuff
that's built there that's confusing things. Cmake should automatically 
tell
that things are old and need to be regenerated, but just to be safe. (I
actually have entirely separate build folders for each branch to make 
sure
thing stay sane.)



Also, probably no need for the entire output. I'm just trying to figure 
out
what the real error message is. Just look through the output and see 
where
it gives you any errors. Don't worry about Doxygen errors. And I know 
you
said you were new to Linux, so treat this as a learning exercise.
Understanding how to grok your compiler output is a really useful skill 
:)



Tom









From: trondeau@trondeau.com [mailto:trondeau@trondeau.com] On Behalf Of 
Tom
Rondeau
Sent: Wednesday, February 20, 2013 3:25 PM
To: Ralph A. Schmid
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] build error with "next" branch



On Wed, Feb 20, 2013 at 9:19 AM, Ralph A. Schmid <ralph@schmid.xxx> 
wrote:

OK, below the output.



"Master" runs just fine through the whole process and runs, so I assume 
the
system should be OK so far. The only non standard stuff on the system is 
a
minimum gnuradio 3.4.2 installation for OpenBTS, some command line tools
that somehow depend on UHD and RTLSDR and maybe gnuradio...



Ralph.



[ 2%] Generating documentation with doxygen

/home/ras/gnuradio/gr-audio/lib/osx/osx_impl.h:57: Warning: include file
boost/detail/endian.hpp not found, perhaps you forgot to add its 
directory
to INCLUDE_PATH?

/home/ras/gnuradio/gruel/src/lib/pmt/pmt_int.h:243: Warning: include 
file
pmt_unv_int.h not found, perhaps you forgot to add its directory to
INCLUDE_PATH?

This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian)

entering extended mode

(./_formulas.tex

LaTeX2e <2009/09/24>

Babel <v3.8l> and hyphenation patterns for english, usenglishmax, 
dumylang,
noh

yphenation, loaded.

(/usr/share/texmf-texlive/tex/latex/base/article.cls

Document Class: article 2007/10/19 v1.4h Standard LaTeX document class

(/usr/share/texmf-texlive/tex/latex/base/size10.clo))

(/usr/share/texmf-texlive/tex/latex/graphics/epsfig.sty

(/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty

(/usr/share/texmf-texlive/tex/latex/graphics/keyval.sty)

(/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty

(/usr/share/texmf-texlive/tex/latex/graphics/trig.sty)

(/etc/texmf/tex/latex/config/graphics.cfg)

(/usr/share/texmf-texlive/tex/latex/graphics/dvips.def))))

No file _formulas.aux.

[1] [2] [3] [4] [5] (./_formulas.aux) )

Output written on _formulas.dvi (5 pages, 1272 bytes).

Transcript written on _formulas.log.

[ 2%] Built target doxygen_target

[ 2%] Generating ../include/gruel/pmt_serial_tags.h

[ 2%] Generating pmt/pmt_unv_int.h, pmt/qa_pmt_unv.h, pmt/pmt_unv.cc,
pmt/qa_pmt_unv.cc

Scanning dependencies of target gruel

[ 2%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_accepter.cc.o

[ 2%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_accepter_msgq.cc.o

[ 2%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_producer.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/msg/msg_queue.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_unv.cc.o

[ 3%] Building CXX object 
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt.cc.o

[ 3%] Building CXX object 
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_io.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_pool.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/pmt/pmt_serialize.cc.o

[ 3%] Building CXX object 
gruel/src/lib/CMakeFiles/gruel.dir/realtime.cc.o

[ 3%] Building CXX object 
gruel/src/lib/CMakeFiles/gruel.dir/sys_pri.cc.o

[ 3%] Building CXX object gruel/src/lib/CMakeFiles/gruel.dir/thread.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/thread_body_wrapper.cc.o

[ 3%] Building CXX object
gruel/src/lib/CMakeFiles/gruel.dir/thread_group.cc.o

Linking CXX shared library libgruel-3.7git.so

make[2]: *** [gruel/src/lib/libgruel-3.7git.so.0.0.0] Error 1

make[1]: *** [gruel/src/lib/CMakeFiles/gruel.dir/all] Error 2

make: *** [all] Error 2



Ralph,



Are you sure this is the entire output? There's nothing indicating what 
the
error was.



Still, I'm wondering if there's a problem with it pulling in installed
versions of the headers as opposed to local versions (we worked to 
correct
this from happening fairly recently, but doesn't mean it's not still
happening here).



Tom

The build and build install worked just fine, but now the crazy thing 
complains
that the pythonpath is not set. Huh?! Why does a new build influence a
environment variable? And I have no idea how to handle these things 
under
Linux :-( So much to learn that I never wanted to know :)

Ralph.

> The build and build install worked just fine, but now the crazy thing
> complains that the pythonpath is not set. Huh?! Why does a new build
> influence a environment variable? And I have no idea how to handle
> these things under Linux :-( So much to learn that I never wanted to
> know :)
>
>
> Ralph.
>
You should set your PYTHONPATH in your .bashrc

I have mine set thusly:

PYTHONPATH=/usr/local/lib64/python2.7/site-packages:$HOME/bin
PYTHONPATH=$PYTHONPATH:/usr/local/lib/python2.7/site-packages:$HOME/bin:.
export PYTHONPATH

You may need to adjust based on your own install environment.

On Wed, Feb 20, 2013 at 12:09 PM, Ralph A. Schmid <ralph@schmid.xxx> 
wrote:

> **
>
> The build and build install worked just fine, but now the crazy thing
> complains that the pythonpath is not set. Huh?! Why does a new build
> influence a environment variable? And I have no idea how to handle these
> things under Linux :-( So much to learn that I never wanted to know :)
>
>
> Ralph.
>


I assure you that the install did not change your environmental 
variables.

To set it, use 'export PYTHONPATH=[path]:$PYTHONPATH'. Some shells want 
you
to use 'set' instead of 'export.' The [path] is the path to the 
installed
Python packages; something like /usr/local/lib/python2.7/dist-packages.

Tom

>
> /usr/local/lib/python2.7/dist-packages.
>
> Tom
>
Indeed, and build-gnuradio actually tells you what your PYTHONPATH
should be set to for Gnu Radio support.  The build-gnuradio script 
*could*
   edit your .bashrc and set that variable for you, but doing so is
dangerous because .bashrc is, essentially, a *program*, which would 
involve
   build-gnuradio somehow interpreting the semantics of said program,
and figuring out where to put the PYTHONPATH setting.  Some hand-holding
   is best left not done...

On Wed, Feb 20, 2013 at 9:09 AM, Ralph A. Schmid <ralph@schmid.xxx> 
wrote:


> So much to learn that I never wanted to know :)
>

It is for this reason that I will be happy when the majority of users
install GNU Radio via operating system vendor supplied packages.  Right 
now
this can be done using Ubuntu 12.10, Debian "testing", and a couple
versions of RedHat Linux (I don't recall the details.)

Johnathan

>
> Johnathan
How up-to-date are the Ubuntu packages?

On Wed, Feb 20, 2013 at 12:23 PM, Marcus D. Leech <mleech@ripnet.com> 
wrote:

> this can be done using Ubuntu 12.10, Debian "testing", and a couple
> versions of RedHat Linux (I don't recall the details.)
>
> Johnathan
>
> How up-to-date are the Ubuntu packages?
>

3.6.1.

Tom

On Wed, Feb 20, 2013 at 9:23 AM, Marcus D. Leech <mleech@ripnet.com> 
wrote:


> How up-to-date are the Ubuntu packages?
>

Release 3.6.1.  If the timing works out, it looks like we can still get
3.6.3 or 3.6.4 (not yet released) into 13.04.

Johnathan

On Wed, Feb 20, 2013 at 6:59 PM, Johnathan Corgan
<johnathan@corganlabs.com> wrote:
> On Wed, Feb 20, 2013 at 9:23 AM, Marcus D. Leech <mleech@ripnet.com> wrote:
>
>>
>> How up-to-date are the Ubuntu packages?
>
> Release 3.6.1.  If the timing works out, it looks like we can still get
> 3.6.3 or 3.6.4 (not yet released) into 13.04.
>

I'm wondering what makes you think that given that the current version
in 13.04 alpha is still 3.6.1?

I don't know if I mentioned it before, but Ubuntu has infrastructure
that can fetch code from a repository and automatically build packages
whenever the code changes, and make the packages available via PPA,
see for example https://launchpad.net/~gpredict-team/+archive/daily
This could be an interesting option as there seems to be an increasing
number of people who are interested in using the latest GNU Radio.

Alex

On Wed, Feb 20, 2013 at 12:41 PM, Alexandru Csete <oz9aec@gmail.com> 
wrote:


>  I'm wondering what makes you think that given that the current version
> in 13.04 alpha is still 3.6.1?
>

Release 3.6.3 has already been packaged for Debian; it's only a matter 
of
coordination to see if it can get into Ubuntu.


> I don't know if I mentioned it before, but Ubuntu has infrastructure
> that can fetch code from a repository and automatically build packages
> whenever the code changes, and make the packages available via PPA,
> see for example https://launchpad.net/~gpredict-team/+archive/daily
> This could be an interesting option as there seems to be an increasing
> number of people who are interested in using the latest GNU Radio.
>

I agree; we've considered this for making versions available that are 
not
yet in the distribution repositories.

If 13.04 stays with 3.6.1, then we'd look at doing a PPA for 3.6.3 or 
3.6.4
as needed.

Johnathan

I can reproduce this behavior; when going back to "master" everything is
fine, switching to "next" brings up a window complaining about the
pythonpath when trying to start grc. I never had set this path manually, 
the
initial installation was done with Marcus' script and worked without 
manual
changes.



Ralph.







From: trondeau@trondeau.com [mailto:trondeau@trondeau.com] On Behalf Of 
Tom
Rondeau
Sent: Wednesday, 20 February, 2013 18:13
To: Ralph A. Schmid
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] build error with "next" branch



On Wed, Feb 20, 2013 at 12:09 PM, Ralph A. Schmid <ralph@schmid.xxx> 
wrote:

The build and build install worked just fine, but now the crazy thing
complains that the pythonpath is not set. Huh?! Why does a new build
influence a environment variable? And I have no idea how to handle these
things under Linux :-( So much to learn that I never wanted to know :)


Ralph.





I assure you that the install did not change your environmental 
variables.



To set it, use 'export PYTHONPATH=[path]:$PYTHONPATH'. Some shells want 
you
to use 'set' instead of 'export.' The [path] is the path to the 
installed
Python packages; something like /usr/local/lib/python2.7/dist-packages.



Tom

Well, this is exactly what everyone recommends _not_ to do, they tell, 
go
with the latest sources.



Ralph.



From: Johnathan Corgan [mailto:johnathan@corganlabs.com]
Sent: Wednesday, 20 February, 2013 18:19
To: Ralph A. Schmid
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] build error with "next" branch



On Wed, Feb 20, 2013 at 9:09 AM, Ralph A. Schmid <ralph@schmid.xxx> 
wrote:



So much to learn that I never wanted to know :)


It is for this reason that I will be happy when the majority of users
install GNU Radio via operating system vendor supplied packages.  Right 
now
this can be done using Ubuntu 12.10, Debian "testing", and a couple 
versions
of RedHat Linux (I don't recall the details.)

Johnathan

On Thu, Feb 21, 2013 at 05:33:24AM +0100, Ralph A. Schmid, dk5ras wrote:
> Well, this is exactly what everyone recommends _not_ to do, they tell, go with
> the latest sources.

Well, we do have crazy release cycles at the moment, and every new
release has *that* critical new feature. This also imposes theoretical
bounds on the quality of the documentation, because it's hard to keep
that up-to-date if the code changes so rapidly.

If the packages were more up-to-date, it would be no problem if people
used them, but right now even the *latest* release often is not enough.

MB


> Cc: discuss-gnuradio@gnu.org
>
> It is for this reason that I will be happy when the majority of users install
> GNU Radio via operating system vendor supplied packages.  Right now this can be
> done using Ubuntu 12.10, Debian "testing", and a couple versions of RedHat
> Linux (I don't recall the details.)
>
> Johnathan
>

> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

On Wed, Feb 20, 2013 at 11:33 PM, Ralph A. Schmid, dk5ras
<ralph@schmid.xxx>wrote:

> Well, this is exactly what everyone recommends _*not*_ to do, they tell,
> go with the latest sources. ****
>
> ** **
>
> Ralph.
>

That's very outdated advice, though understandable. For a long time, the
latest version you could get was 3.2. We now have 3.6.1 available 
through
apt-get on Ubuntu. This is quite new enough for most people. We're lucky
now to have Maitland working closely with us and Debian to make 
up-to-date
versions available.

As Martin said, there's always a desire to have the latest and greatest,
and we are moving quite fast with bug fixes and new features. But those 
new
features also come with their own bugs and issues.

What I'd really like to see happen is that the majority of our users go
with the distributed versions, including the ones available through your
package manager. Only those who are developers or if someone identifies 
a
particular need, feature, bug fix, etc. in the newer code would move to
getting GNU Radio through our git repos.

Tom

On Thu, Feb 21, 2013 at 12:38 AM, Martin Braun (CEL)
<martin.braun@kit.edu>wrote:


> Well, we do have crazy release cycles at the moment, and every new
> release has *that* critical new feature. This also imposes theoretical
> bounds on the quality of the documentation, because it's hard to keep
> that up-to-date if the code changes so rapidly.
>
> If the packages were more up-to-date, it would be no problem if people
> used them, but right now even the *latest* release often is not enough.
>

Yes, we're going through some rather rapid new feature development and 
code
reorganization right now.  Our plan, once we get 3.7 released, is to 
focus
instead on propagating these new features into our existing blocks and
examples, and not do so much deep surgery at the API level.

Johnathan