Hi Jeff, On 16.11.2011 23:07, Jeff Osier-Mixon wrote:
> > Mark & everyone else listening: I include myself in the "everyone" group and answer. ;-) > > Would you say that (1) the need for a recipe and (2) the requirement to > > cross-compile are two of the most major usability or learning-curve > > disadvantages of working with the Yocto Project (and oe-core)? What > > would be a third disadvantage from a usability standpoint? Agree with (1), but not with (2) because in my case cross-compiling with yocto was running "out-of-the-box". Yes, cross-compiling might be difficult and will probably be a pain in the ass for some packages, but its definitely not a big hurdle for a beginner. > > Another way to put it: if you could change three things about the Yocto > > Project to make it more approachable for someone who has never used it > > before, what would they be? Ok, short introduction of my history. - Started playing around with Beagleboard in May. - Used Angstrom/Arago and the TI SDK for that. - Got the wish to create an onw distribution - Meanwhile switched to the TI8148 EVM - Tried OE classic for building an image and failed - Tried OE core for building an image and failed - Got the advice to try Yocto and succeeded in building for Beagleboard - Tried again with OE core and somehow succeeded as well - Now most of the time playing with OE core because my board isn't that well supported in Yocto and I have still to little experience to do it totally myself. So, even working with Linux on the Desktop/Server for more than 14 years I'm still a "newbie" to the embedded Linux world. So I can tell about my wishes in usability very well. :-) First, a beginner wants to be able to have some sort of success. I remember how depressing it was not to be able to build any image, even following the instructions in the web. Later it turned out that a main role in that failure was to blame on our coroporate firewall which I was able to avoid by using a proxy for HTTP, but some packages in OE core need to be fetched from a git repository and git didn't work from scratch. Even having git working on my workstation it still failed inside OE core. Another problem seems, that you always need to work on the *latest* version of the recipe-trees since they are depending from the availability of the upstream sources. If sources change, disappear or move then the recipe needs to be adapted. Now I know that, but in the beginning it was just frustrating to get error messages any time I tried to build something. So my first wish is a "First steps" guide that works and works reproducible. Maybe also with a special "stable" tag in the git tree so that the success is not killed by newer revisions that break something. Second I would like to have a guide that helps me if something goes wrong. Bitbake floods you with messages and for a beginner its not that easy to find out, what was the problem. A sort of "log analyzer" would be fine that says "package xyz failed because of". E.g. if its a fetch problem you could just retry. I also observed a "can't lock /etc/group" lately that went away on the second try, probably another package build (running a nice 12 core system) was interfering with that. The third thing on my wishlist would be a tool that helps me to understand *why* is bitbake xyz-image pulling in that package. So far the commands I used most often in the past weeks were "find" and "grep" to learn about the dependencies and connections between recipes, tasks, classes and conf-files. Probably you've seen the photo of my pinboard on Google+ yesterday. At least now I have a basic understanding of how bitbake handles the things, but I'm still far away from understanding everything. Example: Last week I was able to build systemd-gnome-image with OE core. This week (after some updates of the git trees) I'm not because something is breaking the compilation of samba. So it would be nice to find which task or recipe is pulling in samba (that I really don't need for my image). My usual find & grep shows the following: $ find -name "*\.bb*" | xargs grep "samba" ./meta-openembedded/meta-gnome/recipes-gnome/gvfs/gvfs_1.8.2.bb:DEPENDS = "samba gnome-keyring glib-2.0 fuse avahi fuse gconf libgphoto2" ./meta-openembedded/meta-gnome/recipes-gnome/gvfs/gvfs_1.8.2.bb:EXTRA_OECONF = "--enable-samba \ ./meta-openembedded/meta-gnome/recipes-gnome/gvfs/gvfs_1.8.2.bb: --with-samba-includes=${STAGING_INCDIR} \ ./meta-openembedded/meta-gnome/recipes-gnome/gvfs/gvfs_1.8.2.bb: --with-samba-libs=${STAGING_LIBDIR} \ ./meta-openembedded/meta-gnome/recipes-gnome/gnome-vfs/gnome-vfs_2.24.4.bb: --disable-samba \ So, now I think: What is the difference between "gvfs" and "gnome-vfs" and why is it using "gvfs 1.8.2" (that DEPENDS on samba) instaed of "gnome-vfs 2.24.4" which disables samba (assuming that it is the same function that just got renamed with version 2. The GUI that yocto offers might help in this case, but the few times I tried that gui I was sort of disappointed because the initialization is so damn slow. Ok, those are the 3 main wishes. Unfortuntely there is no "book of OE/yocto" in the book stores so far that is really explaining the stuff for a beginner level (ok, there are probably also no books for the expert level :-)), but old-fashioned that I am I would really like to manage the steep learning curve with the help of a book. Just my 2 cents. Regards Rainer -- Dipl.-Inf. (FH) Rainer Koenig Project Manager Linux Clients Dept. PDG WPS R&D SW OSE Fujitsu Technology Solutions Bürgermeister-Ullrich-Str. 100 86199 Augsburg Germany Telephone: +49-821-804-3321 Telefax: +49-821-804-2131 Mail: mailto:rainer.koe...@ts.fujitsu.com Internet ts.fujtsu.com Company Details ts.fujitsu.com/imprint.html _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto