So I have both UPM and mraa building with NodeJS bindings, that was a matter of setting a proper NodeJS version for the image - I'll have the PR ready shortly. I've used the occassion and updated recipes using the current meta-oe versions, they look the most sane to me. I've also updated mraa and UPM to the latest releases, mraa specifically got quite a few stability fixes/code cleanups between 1.7.0 and 1.8.0, so that makes sense to me.
Building under windows (that would save you working from a virtual machine). Note that building from Ubuntu 17.10 works fine as is.
TBH I don't think this is possible, not natively at least. While some pieces of the Yocto framework do support running on Windows, unless we talk about Windows 10 and WSL (which is in its infancy and there are reported problems with Yocto anyway), I don't think anyone ever targeted Windows as the Yocto build host. One can generate Windows version of an SDK for a Linux distro produced by Yocto, but that's a different story.
And to be honest (and speaking of myself), VM is not only the way to have Linux on Windows - it allows me to have a clean environment separation, albeit at the cost of a performance hit. I'm using Ubuntu 16.04, by the way - also works fine.
Most people will be expecting to use flashall, but you can't at this point. The postbuild script needs to be updated first (when run now it complains it can't find some files, which actually just have a different name), and the env needs to be updated. At this point I like booting from the sd card too much to fix this. Although booting from (and writing to) usb would probably be a lot faster and shorten the build/debug cycle.
Yeah, I believe it would need to be decided, what's the approach we want to have. I can see where running off of the SD card comes in handy (and we can make postbuild write the SD card instead/in addition to flashing) as it allows people to have the official setup as a fallback. I probably would leave this at SD card for now, until the image is stable enough to offer it as a flashable thing.
I would probably focus first on having u-boot and kernel building as a part of the image, I see right now both require separate actions, which looks a bit unnatural (and running "bitbake edison-image" still gets a non-initramfs version of the kernel built).
It would probably be useful to have a recipe build xfstk so recovery works without hassles when needed (I provide binaries right now).
+1 on that - do you think an "issue" on GH would help track it?
I removed the meta-arduino layer, but some recipies may be essential for certain use cases.
Indeed, though I'd be curious whether anyone from the target audience for our images would be interested in running this. Maybe an issue on GH + a call for upvoting? That would help us gauge the interest [of those who find it, anyway].