Okay .. thanks... I've done that and it works with 0.9.0 although I experienced some hiccups with an earlier BSP.
I also referred to this helpful blogpost in the process: http://ph0b.com/adding-dev-tools-gcc-make-to-galileo-sd-image/
With GCC so basic, what is the reasoning for leaving it out of the mainline BSP?
The Galileo has a 400Mhz single core processor and only 256MB RAM. This is ok, if you want to compile smaller programs, but painfull for large one. For example to compile the whole ffmpeg suite, it takes around 4 hours and you have to enable memory swapping to harddisk (read: swapping to the SD card).
Galileo is a terrific learning platform - so compiling small programs directly on the board is great.
For larger application efforts, are there any blogs / guides focused on cross-compiling? It would be great to have titles like this:
1) A guide for cross-compiling to Galileo from GCC running on a desktop
2) An intro to building application recipes for Yocto
Perhaps including simple applications involving just a few files to get started?
Depends on your definition of small I suppose. Packages I have built from source on the Galileo include Ruby, Ruby on Rails, NPT, nano,and git. I find performance compiling on the Galileo to at least equal Ubuntu running in a vmware machine on my big gaming PC.
Just so you know - I've added the directory listing capability to the package repo, so now you should be able to directly browse it without using opkg command line as well as download specific packages.
I'm also removing the Bintray repo later today as announced earlier.
I have both things on my To-Do-list. Unfortunatly my schedule is really crammed, and I still spend my "leisure time" on a bluetooth project with the Galileo.
At least you should give the Yocto Project Reference Manual and the https://wiki.yoctoproject.org/wiki/How_do_I a try. Especially the first one is more a "Guide for blind people who already know how to read braille and use a blindman's stick", but knowledge comes with time (and the mistakes you make).
I already successfully created some recipes to make some permanent changes to /etc/fstab and /etc/network/interfaces to integrate a data partition on the SD card and to connect to my local WLAN without re-configurate this stuff after creating a new image. I promise to write about it in the next days.
 I'm aware that some Intel employees are reading here, but this is the exact feeling I've often got when dealing with opensource software projects where Intel is leading or involved. This includes, but is not limited, to Yocto, OpenCV and the Bluetooth-Stack on Linux called Bluez.
JFYI, I've rebased the package repository at alextgalileo.altervista.org to BSP 0.9.0. That shoudln't really matter for all the application packages (kernel modules may be trickier, but still that's the same kernel version all the time - so chances of incompatibility are low).
That will help me to keep it updated now that 0.8.0 is gone for good. I'll use this release policy, I think - there's a latest BSP image available (+firmware) and the package repo based on it, to have the common ground.
The repo was rebased to BSP v1.0.0. Just as before, that shouldn't affect anything, but feel free to report here if you face problems.
I'm seeing wget connection timeouts to your public repo today. I've confirmed wget is working for other sites. Anyone else seeing this?
Works fine for me right now (though not through wget but a browser, but it shouldn't matter).
I came across this discussion as I'm in the process of setting up package feeds for an i.MX6 based project I'm working on that uses Mono.
I maintain the meta-mono layer at present and it _should_ be as easy as adding the mono recipe to the target image to get this working, e.g. if you look in core-image-mono.inc this is all we do, and it works for me
IMAGE_INSTALL += "libgdiplus mono mono-helloworld"
I'm keen to make meta-mono straightforward to use within Yocto / OpenEmbedded so if you are able to feed back any issues you are having to me then I will take a look.
And of course if anybody wishes to send me an Intel Galileo then I'll be happy to test mono on it
The repo is being rebased to BSP 1.0.1, currently uploading i586 directory with ~1600 packages to go. You may face package download problems until it's done. I'll post here when it's finished.
...and it's finished and works ok for me. Enjoy latest Node.js, Redis and OpenCV 2.4.9 in addition to previously available packages.
I've just discovered that for whatever reason the Packages.gz file, which contains index of the packages, is returned by the web server (or CloudFlare CDN) in unpacked form and that confuses opkg, which expects a gzipped one. You may see error like the below when running "opkg update". The same happens with wget, but doesn't happen with browsers.
The fix is simple - replace "src/gz" with "src" at the beginning of each line in your /etc/opkg/base-feeds.conf. It doesn't change anything, the only drawback is that the package list will be downloaded unpacked right away and would take a couple of seconds longer.
I'm checking out what could be the reason. In the meanwhile if you face this error - please report here, I'm curious if that's server-side or CDN, or just my problem.
root@quark:~/tests# opkg update
Updated list of available packages in /var/lib/opkg/all.
Updated list of available packages in /var/lib/opkg/clanton.
Updated list of available packages in /var/lib/opkg/i586.
* unzip: Invalid gzip magic
* unzip: Invalid gzip magic
* unzip: Invalid gzip magic