[yocto] Yocto usability questions

[Rainer Koenig]

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.Koenig at ts.fujitsu.com

Internet         ts.fujtsu.com
Company Details  ts.fujitsu.com/imprint.html