Wouldn't it be a great service/idea to provide a working correctly setup Debian VM from time to time? 8)
I guess there is one floating around and it is just a matter of sharing.
That would save you quite some time on reading/responding on setup issues 
Best reagrds
Jantje
I fear that would transform setup questions into virtualbox questions 
And debian issues won't be over anyway, since newer packages would require additional prerequisites. It has already happened when we added node packages
@mytrant - you need v8m if you want node.js, if you don't you can disable all the options under Languages->Node.js and then it will let you disable v8m. Or you can work with the 1.0.0 release (see below) which doesn't have node.js, you should end up with something very close to the prebuilt images.
@federico - I might add to your footnote "even then there may be undocumented changes, prepare to learn!"
This brings to light a fact I did not realize even though it is obvious. When you pull from the git GitHub - arduino/openwrt-yun: A custom version of OpenWrt, targeted to the Arduino Yún you get the latest, greatest, PERHAPS buggiest thing available.
If you want to work with the code at a particular point you can use something like git checkout -b release 1.0.0 right after you clone.
To switch back you can use the copy SHA link by the latest commit. At this exact moment in time that would be:
git checkout -b f58425387a0ce96bb709489f526dfaf0dae2e1af
git pull origin f58425387a0ce96bb709489f526dfaf0dae2e1af
I would say somebody needs to improve the OpenWrt tutorial on build root, set up a tutorial on working with things such as debian VM and linino/Yun on a build root in a VM but I learned long ago that it is best to replace "somebody needs to" with "I cheerfully volunteer to" 
noblepepper:
This brings to light a fact I did not realize even though it is obvious. When you pull from the git GitHub - arduino/openwrt-yun: A custom version of OpenWrt, targeted to the Arduino Yún you get the latest, greatest, perhaps buggiest thing available.
Wow! Buggiest!
I know (and sadly accepted) that openwrt build sometime fails, but just really sometime. May you elaborate? Why buggiest?
1.0.0 is different from the latest * only in that it downloads the list of packages from another git repo, GitHub - arduino/openwrt-packages-yun
Since I suspect the git thing may be the source of trouble, I switched the feeds URL to svn
Federico
Thank you for your instructions and footnote - the comment on using the same base world makes sense.
Having worked with other buildroot worlds, I should have followed all the notes to a 'T'.
OpenWRT has enough different build practices (different - not a normal use of Makefile, not a clear path to rebuild sections...) that adding any new changes is not to be recommended.
Thanks to all for any assistance given on these forums as well, it is a good community to ask questions in.
Using hypervisor compare with bear metal will lost % performance, and different type hypervisor will be vary.
Worst case you got hit by 80%
VMware Workstation and VirtualBox is type 2 hypervisor will be suffer more than type 1 hypervisor.
OpenVZ might be best fit: it does not have the overhead of a true hypervisor, it is very fast and efficient. The disadvantage with this approach is the single kernel. All guests must function with the same kernel version that the host uses. My personal experience only lost 5~10%.
Oddly enough am now timewasting....
installed Virtualbox, Debian Wheezy and went to run the following:
apt-get install git subversion build-essential asciidoc \
fastjar flex gawk libgtk2.0-dev intltool zlib1g-dev \
genisoimage libncurses5-dev libssl-dev ruby sdcc unzip \
bison libboost-dev libxml-parser-perl libusb-dev bin86 \
bcc sharutils openjdk-7-jdk mercurial cvs bzr npm
Got the result:
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: unable to locate package npm
Any thoughts on an attempt to build openwrt-yun on the same world?
While I agree with Federico that using the standard build environment will eliminate many problems, I have had a good experience with Ubuntu. I do have to Google occasionally to find the source of an error but I avoid learning vm's and relearning Debian dogma. I am on the last 13.?? Ubuntu but I expect 14.04 won't be too much trouble.
Because it is the latest and greatest! It's the nature of the beast. If you want to be on the bleeding edge you need to be prepared for some issues.
While I envy some of the things you get play with, some of the comments I have seen make me hope you wear asbestos underwear. I am extremely impressed with the yun and what the team has put together.
I also added some emphasis to the perhaps in the original post, it's not ALWAYS the buggiest.
noblepepper:
[quote author=Federico Fissore link=topic=235360.msg1725979#msg1725979 date=1400250481]
Wow! Buggiest!
I know (and sadly accepted) that openwrt build sometime fails, but just really sometime. May you elaborate? Why buggiest?
Because it is the latest and greatest! It's the nature of the beast. If you want to be on the bleeding edge you need to be prepared for some issues.
While I envy some of the things you get play with, some of the comments I have seen make me hope you wear asbestos underwear. I am extremely impressed with the yun and what the team has put together.
I also added some emphasis to the perhaps in the original post, it's not ALWAYS the buggiest.
[/quote]
For the record:
I understood your "perhaps buggiest" remark as "latest and greatest". There is no way to guarantee "regressionless progress".
Best regards
Jantje
mytrant:
Got the result:Reading package lists... Done
Building dependency tree
Reading state information... Done
E: unable to locate package npm
mytrant, you're absolutely right! I've been fooled by the differences between debian and ubuntu once more.
I've changed the prerequisites section replacing apt-get with a script that does the first setup.
I'm running a build with a fresh debian just now. If everything goes well, I'll report later tomorrow evening
It worked fine
Guys, I want to report that I tested the bridge using fileio with the downgraded opwnwrt and a 145 kilobyte text file and it worked perfect
THANK YOU
Sincerely
Rodolfo Magnus
rmagnus:
2) has the speed of the bridge been improved in anyway? If not, how can it be?
you kind of like went from windows 7(linino) to xp(openwrt). how can it not be it is faster?
Best regards
Jantje
I read 144,000 characters in 30 seconds from the SD card .... through the bridge...... so roughly 4,800 chars per second.
it is fast.......
you are right
What I have not found is a safe way to make sure the linux side has booted without the resistor.
THANK YOU
Rodolfo
rmagnus:
Guys, I want to report that I tested the bridge using fileio with the downgraded opwnwrt and a 145 kilobyte text file and it worked perfect
Yeah! 8)
Jantje:
you kind of like went from windows 7(linino) to xp(openwrt). how can it not be it is faster?
XD
rmagnus:
- so without adding any resistors to the yun, what is the best way to know that the linux side has finished booting?
I have an entry in my backlog about Implementing an Arduino Yun boot-status monitor using the handshake signal between the MIPS 24k CPU and the ATMega · GitHub but it's still unplanned
rmagnus:
2) has the speed of the bridge been improved in anyway? If not, how can it be?
That's a kind of an open question. I would like to have a recipe for making it go 10x faster without losing functionalities, but I'm still scratching my head. Any hints are more than welcome
@federico I also tried reading the same 146K bytes at the same time I was playing sound with the madplay player and it worked perfect. You could see somewhat slowed performance but less than I expected. I will keep testing and report back......
I have a question here: I need to look for keys on the Linux datastore using bridge.get () from the arduino side but I don´t want to stop until the key appears there. Is there a way I can do that? Can I just "peek" to see if the key is there and if not, continue with something else? THANK YOU
rmagnus:
I have a question here: I need to look for keys on the Linux datastore using bridge.get () from the arduino side but I don´t want to stop until the key appears there. Is there a way I can do that? Can I just "peek" to see if the key is there and if not, continue with something else? THANK YOU
I would "get" in the loop and do something if the key is found and has the right value
Thank you Federico, if I call bridge.get() function the program will stop if the key is not there yet.
What I want is something like Serial.available() or a way to call bridge.get() where the program does not stop if the key is not found, it returns false or -1 but keeps going.
Is that possible?
The documentation I have found on bridge is very scarce. Maybe I am looking on the wrong place.
Grazie
SIncerely
Rodolfo Magnus