Yocto usability questions

Yocto usability questions

[Jeff Osier-Mixon]

[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]

Mark Hatle said:

> Yocto is a cross-compiled build environment.  This is a departure to a lot
> of the Moblin/MeeGo work that has occurred in the past.  The advantages are
> you can use any commodity PC to target any (supported) architecture.
>  Disadvantages are that when you introduce new code, you need to ensure
> that it has a recipe (build instructions for bitbake) and can cross
> compile.  If everyone has to do the same work over and over, this can be
> time consuming and counter productive.  If people work together, the time
> and support burden are dramatically reduced. This can help negate issues
> people have had in the past with cross compiling. Note: Yocto -does- have a
> self hosted compile environment if it is needed, this is usually when cross
> compiling isn't easy to do for some reason.
>

Mark & everyone else listening:

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?

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?

-- 
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org

[-- Attachment #2: Type: text/html, Size: 1898 bytes --]

Re: Yocto usability questions

[Mark Hatle]

On 11/16/11 4:07 PM, Jeff Osier-Mixon wrote:
> Mark Hatle said:
>
>     Yocto is a cross-compiled build environment. This is a departure to a lot of
>     the Moblin/MeeGo work that has occurred in the past. The advantages are you
>     can use any commodity PC to target any (supported) architecture.
>     Disadvantages are that when you introduce new code, you need to ensure that
>     it has a recipe (build instructions for bitbake) and can cross compile. If
>     everyone has to do the same work over and over, this can be time consuming
>     and counter productive. If people work together, the time and support burden
>     are dramatically reduced. This can help negate issues people have had in the
>     past with cross compiling. Note: Yocto -does- have a self hosted compile
>     environment if it is needed, this is usually when cross compiling isn't easy
>     to do for some reason.
>
>
> Mark & everyone else listening:
>
> 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?

1) Recipe isn't needed, unless you want automatically reproduced builds and to 
share the instructions with others... which is one our our goals.

I don't see the recipe as anything different then an SRPM, Debian src.tgz, etc. 
  The only obstacle is that it's "different" that what desktop distributions do.

2) I think cross compilation is by far the largest obstacle.  People not 
familiar with the GNU auto tools, cross compiling in general, or simply 
inexperienced developers seem to have a lot of problems with this.  I think 
OE/Yocto does a good job at providing GNU auto tools and make helpers, but it's 
far from perfect.  As far as how to improve it...  we need to keep incrementally 
improving our support, documentations and examples.  We also need to foster a 
community where people share the work they've already done... thus eliminating 
this issue.  (The meta-oe layer is a good place for this already.)

I'm sure there are other usability issues, but I've been doing cross compilation 
for so long that I'm a bit blind to some of the issues.

To me the biggest thing we need to do is make sure someone who is familiar with 
desktop Linux can step in and apply what they know to building a recipe and 
fixing cross compilation problems.  If we can do that -- it will go a long way 
toward helping resolve the issues that cause people to do self-hosted 
compilation on slow target systems.  (Note there are some things that are simply 
complicated and difficult to do like Firefox.. for those the only answer is to 
have "experts" do the work and make it available to the novices so they can see 
and understand how to work around various issues.)

> 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?

To re-iterate:

*) We need a resource for contributed packages (meta-oe?) that will eliminate 
most of the problem.

*) We need good examples of problems and solutions to cross compilation difficulties

*) We need to continue to identify "common" issues and work to resolve them in 
the tooling we already support

--Mark

> --
> Jeff Osier-Mixon http://jefro.net/blog
> Yocto Project Community Manager @Intel http://yoctoproject.org
> <http://yoctoproject.org/>
>
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Yocto usability questions

[Ourada, Paul]

I apologize in advance for the top-post.

Like Mark, I'm a  20+ year veteran of "ordinary" embedded development, and so cross compilation is old hat for me as well. The usual commercial cross compilers, linkers, RTOSes, debuggers, and other libraries are usually fairly well integrated. Those types of environments tolerate their host environments fairly well, because it's pretty easy to keep everything separated.

I am much newer to Linux and embedded Linux development. I haven't used the SDK for Yocto yet, but I have used the Timesys SDK a little. For writing new code/apps, it's fairly straightforward - set up some environment variables, write a makefile and use cross_make, cross_configure, etc. I set up the embedded target to PXE boot, which keeps all executables and RFS on the host workstation. So for development one merely needs to drop the compiled app and any required configuration onto the RFS on the workstation. For writing kernel-level stuff, such as kernel mode drivers, one pretty much has to use the TimeSys factory (an extension to the kernel make environment from what I can tell).  

If one wants to use the TimeSys factory so that proprietary apps are built and loaded/installed into the RFS automagically, or build packages which are not on the TimeSys server, then one writes what is essentially the equivalent of the bitbake recipe, only in makefile format. It has all the same sorts of process steps: fetch, unpack, patch, auto/configure, compile, install.

Of course PXE boot can be set up for Yocto projects - I've already done it for the Kontron Atom board we're going to use in our next product. I hacked out the bzImage and root file system from the cpio image and plopped them into the tftpboot and exported rfs directory, and bingo - PXE booting!

Frankly, as a medical device software developer, I find the "recipe/makefile" paradigm much more familiar and preferable to the "app" developer paradigm. We have to be able to recreate bit-accurate images for our devices. A relatively consistent paradigm for accomplishing this is much better than cobbling together a bunch of ad hoc scripts.

At any rate, it seems to me that writing recipes is writing recipes, just like once you've used 3 or 4 editors or word processors, then you pretty much know what the score is when you go to pick up the 5th. Bitbake recipes aren't all that different from makefiles, except for the syntax,and learning the various meanings of different "build variables" -- oh, and using bitbake/python as glueinstead of jam, or make. I think that this has been the biggest source of frustration for me wrt to Yocto: Trying to map what I already know onto a new paradigm. I know - after 20 years, the mud gets a little thick and hard. ;)

But I understand the need to make things easier for the less experienced developer. And I get that cross compiling an embedded Linux OS is more intertwined with the host workstation OS than other RTOSes, even when they are compiled on a *nix workstation. One way that I'm addressing this for my development team (which has several never-done-Linux-no-way-no-how types) is finding links to relevant tutorials and sprinkling them in places they're likely to need the info. Although there is a ton of documentation out there, it's not always in easy to find places.

As a relative newcomer to Yocto and OE and bitbake, I can't agree with Mark more regarding examples and documentation. I'd suggest that you make a part of your process finding an inexperienced someone to run through your documentation and try to implement the various different features, or demonstrate knowledge of key concepts. The questions such a person might ask are likely pointers to holes in your documentation or process. This could be a good Google Summer of Code type exercise. Not as sexy as some, but definitely a big payoff for Yocto.

Mark mentioned the need for adding packages which are not already in the recipe base, but perhaps already exist in a desktop form. Making it easy to contribute seems like a common FOSS practice. For the difficulty aspect, someone mentioned in the Qt/OpenSSL thread recently that RPMs have a lot of the dependency information built into them, and I suspect also configuration files for install, or recipes for creating them. I also read in one of the Yocto blogs that someone on the Kernel side created a script to keep Kconfig fragments synched across BSPs. Might it be possible to write a script to mine a desktop RPM (or any other usable package format), and their associated makefile(s) to create as much of the bones of a bitbake recipe as can be gleaned from the desktop package? It might be as complex a task as the automake process itself. :)

Hope there was some useful information in there somewhere. :)

Paul Ourada
Sr Principal Software Engineer
Covidien, Surgical Solutions, Energy-based Devices

________________________________________
From: yocto-bounces@yoctoproject.org [yocto-bounces@yoctoproject.org] on behalf of Mark Hatle [mark.hatle@windriver.com]
Sent: Wednesday, November 16, 2011 4:39 PM
To: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto usability questions

On 11/16/11 4:07 PM, Jeff Osier-Mixon wrote:
> Mark Hatle said:
>
>     Yocto is a cross-compiled build environment. This is a departure to a lot of
>     the Moblin/MeeGo work that has occurred in the past. The advantages are you
>     can use any commodity PC to target any (supported) architecture.
>     Disadvantages are that when you introduce new code, you need to ensure that
>     it has a recipe (build instructions for bitbake) and can cross compile. If
>     everyone has to do the same work over and over, this can be time consuming
>     and counter productive. If people work together, the time and support burden
>     are dramatically reduced. This can help negate issues people have had in the
>     past with cross compiling. Note: Yocto -does- have a self hosted compile
>     environment if it is needed, this is usually when cross compiling isn't easy
>     to do for some reason.
>
>
> Mark & everyone else listening:
>
> 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?

1) Recipe isn't needed, unless you want automatically reproduced builds and to
share the instructions with others... which is one our our goals.

I don't see the recipe as anything different then an SRPM, Debian src.tgz, etc.
  The only obstacle is that it's "different" that what desktop distributions do.

2) I think cross compilation is by far the largest obstacle.  People not
familiar with the GNU auto tools, cross compiling in general, or simply
inexperienced developers seem to have a lot of problems with this.  I think
OE/Yocto does a good job at providing GNU auto tools and make helpers, but it's
far from perfect.  As far as how to improve it...  we need to keep incrementally
improving our support, documentations and examples.  We also need to foster a
community where people share the work they've already done... thus eliminating
this issue.  (The meta-oe layer is a good place for this already.)

I'm sure there are other usability issues, but I've been doing cross compilation
for so long that I'm a bit blind to some of the issues.

To me the biggest thing we need to do is make sure someone who is familiar with
desktop Linux can step in and apply what they know to building a recipe and
fixing cross compilation problems.  If we can do that -- it will go a long way
toward helping resolve the issues that cause people to do self-hosted
compilation on slow target systems.  (Note there are some things that are simply
complicated and difficult to do like Firefox.. for those the only answer is to
have "experts" do the work and make it available to the novices so they can see
and understand how to work around various issues.)

> 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?

To re-iterate:

*) We need a resource for contributed packages (meta-oe?) that will eliminate
most of the problem.

*) We need good examples of problems and solutions to cross compilation difficulties

*) We need to continue to identify "common" issues and work to resolve them in
the tooling we already support

--Mark

> --
> Jeff Osier-Mixon http://jefro.net/blog
> Yocto Project Community Manager @Intel http://yoctoproject.org
> <http://yoctoproject.org/>
>
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: Yocto usability questions

[Koen Kooi]

Op 16 nov. 2011, om 23:07 heeft Jeff Osier-Mixon het volgende geschreven:

> Mark Hatle said:
> Yocto is a cross-compiled build environment.

I thought yocto was an umbrella project, not a build env. Openembedded-core is a  cross-compiled build environment, which poky (part of yocto) is based on.

Can we please get the messaging straight? If not, please rename poky to yocto.

Re: 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@ts.fujitsu.com

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

Re: Yocto usability questions

[Philip Balister]

On 11/17/2011 08:06 AM, Rainer Koenig wrote:
> 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. ;-)
> 
> 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.
> 

This is the number one issue with the openembedded-core/meta-oe
combination. There is no system in place to publish a list of known good
revisions for people who are trying to get real work done. Currently,
I'm stuck because guile won't build. (I also see the samba issue, but
dropped it from gvfs). I've been around a long time, and there are still
some build issues that stump me. Personally, I need this stuff to work
so I can get stuff done for paying customers. I don't care if recipes
are perfect, or we have the latest version of everything, something that
builds reliably on a number of build machine distros is what we really need.

Philip

Re: Yocto usability questions

[Chris Tapp]

On 16 Nov 2011, at 22:07, Jeff Osier-Mixon wrote:

> Mark & everyone else listening:
>
> 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?
>
> 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?

As another very experienced embedded systems developer who is  
relatively new to embedded linux I would say that documentation and  
worked examples are what I would really be after.

It can be really frustrating when you can't get something going  
because you don't understand the phrases / terminology that's being  
used and it isn't readily available via the documentation. I've seen  
quite a few posts on here relating to the documentation and it does  
look like good progress is being made. As someone said earlier in this  
thread, it would be good it run stuff through new (or relatively new)  
adopters to see if they can get the examples to work without a fight.  
I'm more than happy to help (and learn!).

I to started with OE and failed to get a build to complete. Yocto got  
me there first time, so it is already much better for a novice 'baker' !

Some worked examples for 'how to do xxx' would also be nice. E.g.

1) How do I configure the kernel ?
2) What do I need to do when I change my recipe to ensure that the  
changes make it in to the image ?
3) How do I change and add startup scripts ?
4) How do I add data files to the image ?
5) How do I make sure dependencies (e.g. libraries) are included in  
the image ? i.e. what do DEPENDS, RDEPENDS, etc. do.
6) How can I use a layer to hold my project files ?
7) Do I need to delete tmp/ and rebuild to ensure I've got a valid  
project build configured ? (i.e. it doesn't rely on staged items that  
don't build when I bitbake MyProject).
8) How do I make my existing autobuild project in to a recipe ?
9) How do I set / change the root password ?

These items would help explain how to create a recipe and to use  
bbappend. Ideally they should be worded so that they can be followed  
by someone with a general embedded background who has minimal exposure  
to embedded linux. However, it probably doesn't want to be an embedded  
linux primer.

This project is already easier to use than many others and is  
supported by a really knowledgeable group who are willing to help  
newcomers out. As it grows it would be unreasonable to expect the same  
(relatively small) group to be able to support a much wider user-base.  
Comprehensive documentation and non-trivial worked example should help  
to reduce the workload and allow the group to assist those who have a  
genuine need of help.

Chris Tapp

opensource@keylevel.com
www.keylevel.com

Re: Yocto usability questions

[Brian Duffy]

[-- Attachment #1: Type: text/plain, Size: 4220 bytes --]

On Thu, Nov 17, 2011 at 4:38 PM, Chris Tapp <opensource@keylevel.com> wrote:

> On 16 Nov 2011, at 22:07, Jeff Osier-Mixon wrote:
>
>  Mark & everyone else listening:
>>
>> 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?
>>
>> 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?
>>
>
> As another very experienced embedded systems developer who is relatively
> new to embedded linux I would say that documentation and worked examples
> are what I would really be after.
>
> It can be really frustrating when you can't get something going because
> you don't understand the phrases / terminology that's being used and it
> isn't readily available via the documentation. I've seen quite a few posts
> on here relating to the documentation and it does look like good progress
> is being made. As someone said earlier in this thread, it would be good it
> run stuff through new (or relatively new) adopters to see if they can get
> the examples to work without a fight. I'm more than happy to help (and
> learn!).
>
> I to started with OE and failed to get a build to complete. Yocto got me
> there first time, so it is already much better for a novice 'baker' !
>
> Some worked examples for 'how to do xxx' would also be nice. E.g.
>
> 1) How do I configure the kernel ?
> 2) What do I need to do when I change my recipe to ensure that the changes
> make it in to the image ?
> 3) How do I change and add startup scripts ?
> 4) How do I add data files to the image ?
> 5) How do I make sure dependencies (e.g. libraries) are included in the
> image ? i.e. what do DEPENDS, RDEPENDS, etc. do.
> 6) How can I use a layer to hold my project files ?
> 7) Do I need to delete tmp/ and rebuild to ensure I've got a valid project
> build configured ? (i.e. it doesn't rely on staged items that don't build
> when I bitbake MyProject).
> 8) How do I make my existing autobuild project in to a recipe ?
> 9) How do I set / change the root password ?
>
> These items would help explain how to create a recipe and to use bbappend.
> Ideally they should be worded so that they can be followed by someone with
> a general embedded background who has minimal exposure to embedded linux.
> However, it probably doesn't want to be an embedded linux primer.
>
> This project is already easier to use than many others and is supported by
> a really knowledgeable group who are willing to help newcomers out. As it
> grows it would be unreasonable to expect the same (relatively small) group
> to be able to support a much wider user-base. Comprehensive documentation
> and non-trivial worked example should help to reduce the workload and allow
> the group to assist those who have a genuine need of help.
>
> Chris Tapp
>
> opensource@keylevel.com
> www.keylevel.com
>
>
> ______________________________**_________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.**org/listinfo/yocto<https://lists.yoctoproject.org/listinfo/yocto>
>

I disagree somewhat. I think the goal, as implied on the website homepage
video, is (and should be) to include new comers and foster an environment
where embedded development is somewhat more demystified. Experienced
embedded developers may be inclined to stick with what they know works for
them, but someone who decides they have a cool idea and is a good
developer, but never has built an embedded system before would be the
better user to target in my opinion. The team seems to be making good
progress in that direction and I will add my hat to the school of thought
that encourages focusing on extremely good documentation with simple and
advanced use cases, together with a workflow example for getting from
application idea to device. It may be a lot of work but without it you lose
so many potential developers.

-- 
Duff

[-- Attachment #2: Type: text/html, Size: 5107 bytes --]

Re: Yocto usability questions

[Osier-mixon, Jeffrey]

[-- Attachment #1: Type: text/plain, Size: 297 bytes --]

I'm really glad to see the amazing in-depth answers on this thread!  These
ideas are extremely valuable in guiding us. Many thanks to those answering
& please keep up the good words!

-- 
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org

[-- Attachment #2: Type: text/html, Size: 1166 bytes --]

Re: Yocto usability questions

[Jack Mitchell]

[-- Attachment #1: Type: text/plain, Size: 5363 bytes --]

On 17/11/2011 21:38, Chris Tapp wrote:
> On 16 Nov 2011, at 22:07, Jeff Osier-Mixon wrote:
>
>> Mark & everyone else listening:
>>
>> 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?
>>
>> 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?
>
> As another very experienced embedded systems developer who is 
> relatively new to embedded linux I would say that documentation and 
> worked examples are what I would really be after.
>
I am a fairly in-experienced embedded systems developer (fresh graduate, 
6 months real work exp) and have used Linux for a few years now and I 
concur that written examples, tutorials if you will, would be a great idea.
> It can be really frustrating when you can't get something going 
> because you don't understand the phrases / terminology that's being 
> used and it isn't readily available via the documentation. I've seen 
> quite a few posts on here relating to the documentation and it does 
> look like good progress is being made. As someone said earlier in this 
> thread, it would be good it run stuff through new (or relatively new) 
> adopters to see if they can get the examples to work without a fight. 
> I'm more than happy to help (and learn!).
It is very frustrating when you come to an issue that isn't documented, 
however I have found the IRC an invaluable resource as well as this 
mailing list. If documentation was to become more extensive I feel the 
categories should be defined further and split into more documents.
>
> I to started with OE and failed to get a build to complete. Yocto got 
> me there first time, so it is already much better for a novice 'baker' !
>
> Some worked examples for 'how to do xxx' would also be nice. E.g.
>
> 1) How do I configure the kernel ?
This has been covered fairly extensively but a full worked example 
wouldn't go amiss.
> 2) What do I need to do when I change my recipe to ensure that the 
> changes make it in to the image ?
I don't know how to properly do this so +1
> 3) How do I change and add startup scripts ?
I read a lot about startup scripts to figure out how to do this the 
correct way - although it is more generic linux knowledge I believe an 
easy introduction to this with further reading wouldn't go amiss.
>
> 4) How do I add data files to the image ?
I would image these to go in with the software you are developing.. 
however the fact I don't have a good answer may mean it needs addressing?
> 5) How do I make sure dependencies (e.g. libraries) are included in 
> the image ? i.e. what do DEPENDS, RDEPENDS, etc. do.
See 8
> 6) How can I use a layer to hold my project files ?
See 8
> 7) Do I need to delete tmp/ and rebuild to ensure I've got a valid 
> project build configured ? (i.e. it doesn't rely on staged items that 
> don't build when I bitbake MyProject).
Would be very good to get an example of how to ensure your build process 
is stable and will work every time from scratch.
> 8) How do I make my existing autobuild project in to a recipe ?
*THIS.* I currently have no idea how to port my autobuild project coded 
using the Eclipse plugin to a recipe structure, couple this with 5 and 6 
and it would make a fantastic from 'start to finish' style manual.
> 9) How do I set / change the root password ?
This seems fairly minor, is there a section in the wiki which could be 
devoted to things like this, rather than the faff of creating a new pdf 
etc.. this would also allow for the community to add tricks and tips in 
an easily accessible manner.

I have had reams of help from the users and project employees already 
for which I am very grateful. I think this is a fantastic project and 
something I will definitely keep with. I am currently in the process of 
proposing this as my new companies base architecture and will hopefully 
be becoming very adept in OE and Yocto over the coming year.

Thanks for all the work done and help provided so far, may it continue!

Jack.

>
> These items would help explain how to create a recipe and to use 
> bbappend. Ideally they should be worded so that they can be followed 
> by someone with a general embedded background who has minimal exposure 
> to embedded linux. However, it probably doesn't want to be an embedded 
> linux primer.
>
> This project is already easier to use than many others and is 
> supported by a really knowledgeable group who are willing to help 
> newcomers out. As it grows it would be unreasonable to expect the same 
> (relatively small) group to be able to support a much wider user-base. 
> Comprehensive documentation and non-trivial worked example should help 
> to reduce the workload and allow the group to assist those who have a 
> genuine need of help.
>
> Chris Tapp
>
> opensource@keylevel.com
> www.keylevel.com
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto


[-- Attachment #2: Type: text/html, Size: 8065 bytes --]

Re: Yocto usability questions

[Ourada, Paul]

Jack said:
>From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Jack Mitchell
>Sent: Friday, November 18, 2011 2:40 AM
>To: yocto@yoctoproject.org
>Subject: Re: [yocto] Yocto usability questions
>
>On 17/11/2011 21:38, Chris Tapp wrote: 
>On 16 Nov 2011, at 22:07, Jeff Osier-Mixon wrote: 
>
>
>Mark & everyone else listening: 
>
>
>It is very frustrating when you come to an issue that isn't documented, however I have found the IRC an invaluable >resource as well as this mailing list. If documentation was to become more extensive I feel the categories should be >defined further and split into more documents.

I would just add that for some corporate/enterprise customers (such as myself), while IRC is great, it isn't as great an option because corporate IS locks down IRC protocols. To use IRC, I would have to do so from a non-work computer and likely outside of normal work hours, of which I already put in way more than my wife would prefer. :)

I really like Jack's list, though. I would like to pile on (again :)) that documentation, examples and explanation of terms are very important.

Paul

Paul E. Ourada
Sr. Principal Software Engineer
Covidien, Energy-based Devices
5920 Longbow Drive
Boulder, CO 80301
paul.ourada@covidien.com
www.covidien.com
Main: 303-530-2300
Ofc: 303-581-6940
Fax: 303-581-6741

Re: Yocto usability questions

[Philip Balister]

On 11/18/2011 10:02 AM, Ourada, Paul wrote:
> Jack said:
>> From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Jack Mitchell
>> Sent: Friday, November 18, 2011 2:40 AM
>> To: yocto@yoctoproject.org
>> Subject: Re: [yocto] Yocto usability questions
>>
>> On 17/11/2011 21:38, Chris Tapp wrote: 
>> On 16 Nov 2011, at 22:07, Jeff Osier-Mixon wrote: 
>>
>>
>> Mark & everyone else listening: 
>>
>>
>> It is very frustrating when you come to an issue that isn't documented, however I have found the IRC an invaluable >resource as well as this mailing list. If documentation was to become more extensive I feel the categories should be >defined further and split into more documents.
> 
> I would just add that for some corporate/enterprise customers (such as myself), while IRC is great, it isn't as great an option because corporate IS locks down IRC protocols. To use IRC, I would have to do so from a non-work computer and likely outside of normal work hours, of which I already put in way more than my wife would prefer. :)

If I had a nickel for the .com guys ssh'ing into their home computers
(many times on non-standard ports) to run irc to get their work done,
I'd be retired :)

Philip

> 
> I really like Jack's list, though. I would like to pile on (again :)) that documentation, examples and explanation of terms are very important.
> 
> Paul
> 
> Paul E. Ourada
> Sr. Principal Software Engineer
> Covidien, Energy-based Devices
> 5920 Longbow Drive
> Boulder, CO 80301
> paul.ourada@covidien.com
> www.covidien.com
> Main: 303-530-2300
> Ofc: 303-581-6940
> Fax: 303-581-6741
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
> 

Re: Yocto usability questions

[Gary Thomas]

On 2011-11-18 08:02, Ourada, Paul wrote:
> Jack said:
>> From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Jack Mitchell
>> Sent: Friday, November 18, 2011 2:40 AM
>> To: yocto@yoctoproject.org
>> Subject: Re: [yocto] Yocto usability questions
>>
>> On 17/11/2011 21:38, Chris Tapp wrote:
>> On 16 Nov 2011, at 22:07, Jeff Osier-Mixon wrote:
>>
>>
>> Mark&  everyone else listening:
>>
>>
>> It is very frustrating when you come to an issue that isn't documented, however I have found the IRC an invaluable>resource as well as this mailing list. If documentation was to become more extensive I feel the categories should be>defined further and split into more documents.
>
> I would just add that for some corporate/enterprise customers (such as myself), while IRC is great, it isn't as great an option because corporate IS locks down IRC protocols. To use IRC, I would have to do so from a non-work computer and likely outside of normal work hours, of which I already put in way more than my wife would prefer. :)

IMO, IRC is like gossip - only those present learn anything :-(  I think information
should be shared and archived and IRC doesn't really cover that.  That's part of why
I pepper these lists with questions and problems and ...

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Yocto usability questions

[Philip Balister]

On 11/18/2011 10:56 AM, Gary Thomas wrote:
> On 2011-11-18 08:02, Ourada, Paul wrote:
>> Jack said:
>>> From: yocto-bounces@yoctoproject.org
>>> [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Jack Mitchell
>>> Sent: Friday, November 18, 2011 2:40 AM
>>> To: yocto@yoctoproject.org
>>> Subject: Re: [yocto] Yocto usability questions
>>>
>>> On 17/11/2011 21:38, Chris Tapp wrote:
>>> On 16 Nov 2011, at 22:07, Jeff Osier-Mixon wrote:
>>>
>>>
>>> Mark&  everyone else listening:
>>>
>>>
>>> It is very frustrating when you come to an issue that isn't
>>> documented, however I have found the IRC an invaluable>resource as
>>> well as this mailing list. If documentation was to become more
>>> extensive I feel the categories should be>defined further and split
>>> into more documents.
>>
>> I would just add that for some corporate/enterprise customers (such as
>> myself), while IRC is great, it isn't as great an option because
>> corporate IS locks down IRC protocols. To use IRC, I would have to do
>> so from a non-work computer and likely outside of normal work hours,
>> of which I already put in way more than my wife would prefer. :)
> 
> IMO, IRC is like gossip - only those present learn anything :-(  I think
> information
> should be shared and archived and IRC doesn't really cover that.  That's
> part of why
> I pepper these lists with questions and problems and ...
> 

Good irc channels are logged and the logs will be hit with google searches.

Philip

Re: Yocto usability questions

[Gary Thomas]

On 2011-11-18 09:00, Philip Balister wrote:
> On 11/18/2011 10:56 AM, Gary Thomas wrote:
>> On 2011-11-18 08:02, Ourada, Paul wrote:
>>> Jack said:
>>>> From: yocto-bounces@yoctoproject.org
>>>> [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Jack Mitchell
>>>> Sent: Friday, November 18, 2011 2:40 AM
>>>> To: yocto@yoctoproject.org
>>>> Subject: Re: [yocto] Yocto usability questions
>>>>
>>>> On 17/11/2011 21:38, Chris Tapp wrote:
>>>> On 16 Nov 2011, at 22:07, Jeff Osier-Mixon wrote:
>>>>
>>>>
>>>> Mark&   everyone else listening:
>>>>
>>>>
>>>> It is very frustrating when you come to an issue that isn't
>>>> documented, however I have found the IRC an invaluable>resource as
>>>> well as this mailing list. If documentation was to become more
>>>> extensive I feel the categories should be>defined further and split
>>>> into more documents.
>>>
>>> I would just add that for some corporate/enterprise customers (such as
>>> myself), while IRC is great, it isn't as great an option because
>>> corporate IS locks down IRC protocols. To use IRC, I would have to do
>>> so from a non-work computer and likely outside of normal work hours,
>>> of which I already put in way more than my wife would prefer. :)
>>
>> IMO, IRC is like gossip - only those present learn anything :-(  I think
>> information
>> should be shared and archived and IRC doesn't really cover that.  That's
>> part of why
>> I pepper these lists with questions and problems and ...
>>
>
> Good irc channels are logged and the logs will be hit with google searches.

But that's hardly the same as having the "conversation(s)" delivered to my desk,
along with [normally] useful subject lines, that I can peruse at will.  It's
the difference between push [mailing lists] and pull [IRC logs].

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Yocto usability questions

[Tom Rini]

On Fri, Nov 18, 2011 at 9:04 AM, Gary Thomas <gary@mlbassoc.com> wrote:
> On 2011-11-18 09:00, Philip Balister wrote:
>>
>> On 11/18/2011 10:56 AM, Gary Thomas wrote:
>>>
>>> On 2011-11-18 08:02, Ourada, Paul wrote:
>>>>
>>>> Jack said:
>>>>>
>>>>> From: yocto-bounces@yoctoproject.org
>>>>> [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Jack Mitchell
>>>>> Sent: Friday, November 18, 2011 2:40 AM
>>>>> To: yocto@yoctoproject.org
>>>>> Subject: Re: [yocto] Yocto usability questions
>>>>>
>>>>> On 17/11/2011 21:38, Chris Tapp wrote:
>>>>> On 16 Nov 2011, at 22:07, Jeff Osier-Mixon wrote:
>>>>>
>>>>>
>>>>> Mark&   everyone else listening:
>>>>>
>>>>>
>>>>> It is very frustrating when you come to an issue that isn't
>>>>> documented, however I have found the IRC an invaluable>resource as
>>>>> well as this mailing list. If documentation was to become more
>>>>> extensive I feel the categories should be>defined further and split
>>>>> into more documents.
>>>>
>>>> I would just add that for some corporate/enterprise customers (such as
>>>> myself), while IRC is great, it isn't as great an option because
>>>> corporate IS locks down IRC protocols. To use IRC, I would have to do
>>>> so from a non-work computer and likely outside of normal work hours,
>>>> of which I already put in way more than my wife would prefer. :)
>>>
>>> IMO, IRC is like gossip - only those present learn anything :-(  I think
>>> information
>>> should be shared and archived and IRC doesn't really cover that.  That's
>>> part of why
>>> I pepper these lists with questions and problems and ...
>>>
>>
>> Good irc channels are logged and the logs will be hit with google
>> searches.
>
> But that's hardly the same as having the "conversation(s)" delivered to my
> desk,
> along with [normally] useful subject lines, that I can peruse at will.  It's
> the difference between push [mailing lists] and pull [IRC logs].

The problem goes like this.  Some projects tend to keep all of their
technical discussions on the mailing list, so this works great.  But,
OE isn't one of those.  I think we try and keep the "big items" at
least summarized on the mailing lists, but at the end of the day, if
you know you need to ask $someone what they think, and you're on IRC
(or gchat or skype or ...) and they are too, you can either bug them
real time, or email them long form (or the dreaded but happens in
companies, 10 emails in 2 minutes, top posting questions/answers back
and forth, with some list in tow).

I don't know if this was a conscious choice of the project or not, but
at the end of the day, if you want to know everything you need to also
skim the logs for #oe and #yocto (and if you're angstrom, #angstrom).
That said, I think the IRC logging bots could use a kick into this
decade and some RSS feeds would sure help folks actually follow along
rather than just waiting on google to index the text files.

-- 
Tom

Re: Yocto usability questions

[Jack Mitchell]

[-- Attachment #1: Type: text/plain, Size: 2372 bytes --]

On 18/11/2011 16:04, Gary Thomas wrote:
> On 2011-11-18 09:00, Philip Balister wrote:
>> On 11/18/2011 10:56 AM, Gary Thomas wrote:
>>> On 2011-11-18 08:02, Ourada, Paul wrote:
>>>> Jack said:
>>>>> From: yocto-bounces@yoctoproject.org
>>>>> [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Jack Mitchell
>>>>> Sent: Friday, November 18, 2011 2:40 AM
>>>>> To: yocto@yoctoproject.org
>>>>> Subject: Re: [yocto] Yocto usability questions
>>>>>
>>>>> On 17/11/2011 21:38, Chris Tapp wrote:
>>>>> On 16 Nov 2011, at 22:07, Jeff Osier-Mixon wrote:
>>>>>
>>>>>
>>>>> Mark&   everyone else listening:
>>>>>
>>>>>
>>>>> It is very frustrating when you come to an issue that isn't
>>>>> documented, however I have found the IRC an invaluable>resource as
>>>>> well as this mailing list. If documentation was to become more
>>>>> extensive I feel the categories should be>defined further and split
>>>>> into more documents.
>>>>
>>>> I would just add that for some corporate/enterprise customers (such as
>>>> myself), while IRC is great, it isn't as great an option because
>>>> corporate IS locks down IRC protocols. To use IRC, I would have to do
>>>> so from a non-work computer and likely outside of normal work hours,
>>>> of which I already put in way more than my wife would prefer.
>>>
>>> IMO, IRC is like gossip - only those present learn anything   I think
>>> information
>>> should be shared and archived and IRC doesn't really cover that.  
>>> That's
>>> part of why
>>> I pepper these lists with questions and problems and ...
>>>
>>
>> Good irc channels are logged and the logs will be hit with google 
>> searches.
>
> But that's hardly the same as having the "conversation(s)" delivered 
> to my desk,
> along with [normally] useful subject lines, that I can peruse at 
> will.  It's
> the difference between push [mailing lists] and pull [IRC logs].
>

Quite often I will only use IRC if a problem is specific to something I 
am doing. If it is an actual issue then the problem should be relayed to 
the bug tracker and fixed. For example, nobody wants to know why my 
layer called xyz with package zyx won't compile because I used a wrong 
bitbake flag, however if it turns out to be a compilation bug or a flag 
that isn't documented then it will be pushed to the bug tracker and 
hopefully fixed.

[-- Attachment #2: Type: text/html, Size: 4799 bytes --]

Re: Yocto usability questions

[Osier-mixon, Jeffrey]

[-- Attachment #1: Type: text/plain, Size: 869 bytes --]

On Fri, Nov 18, 2011 at 7:02 AM, Ourada, Paul <Paul.Ourada@covidien.com>wrote:

>
> I would just add that for some corporate/enterprise customers (such as
> myself), while IRC is great, it isn't as great an option because corporate
> IS locks down IRC protocols. To use IRC, I would have to do so from a
> non-work computer and likely outside of normal work hours, of which I
> already put in way more than my wife would prefer. :)
>

Hi Paul - I would never endorse an end-run around anyone's corporate rules,
and I strongly encourage you to talk to your boss and IT's boss about
enabling IRC.

That being said - you can connect to IRC at Freenode on a webpage at
webchat.freenode.net. I recommend this often to folks who have proxy issues.

-- 
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org

[-- Attachment #2: Type: text/html, Size: 1347 bytes --]

Re: Yocto usability questions

[Jeff Osier-Mixon]

[-- Attachment #1: Type: text/plain, Size: 300 bytes --]

NOTE to all of the participants in this great discussion - if you don't
have a Yocto t-shirt already, let me know your size and address and I'll
get you one in the next couple of weeks.

-- 
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org

[-- Attachment #2: Type: text/html, Size: 465 bytes --]

Re: Yocto usability questions

[Joshua Lock]

On 18/11/11 01:40, Jack Mitchell wrote:
> On 17/11/2011 21:38, Chris Tapp wrote:
>> On 16 Nov 2011, at 22:07, Jeff Osier-Mixon wrote:
>>
>>> Mark & everyone else listening:
>>>
>>> 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?
>>>
>>> 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?
>>
>> As another very experienced embedded systems developer who is
>> relatively new to embedded linux I would say that documentation and
>> worked examples are what I would really be after.
>>
> I am a fairly in-experienced embedded systems developer (fresh graduate,
> 6 months real work exp) and have used Linux for a few years now and I
> concur that written examples, tutorials if you will, would be a great idea.
>> It can be really frustrating when you can't get something going
>> because you don't understand the phrases / terminology that's being
>> used and it isn't readily available via the documentation. I've seen
>> quite a few posts on here relating to the documentation and it does
>> look like good progress is being made. As someone said earlier in this
>> thread, it would be good it run stuff through new (or relatively new)
>> adopters to see if they can get the examples to work without a fight.
>> I'm more than happy to help (and learn!).
> It is very frustrating when you come to an issue that isn't documented,
> however I have found the IRC an invaluable resource as well as this
> mailing list. If documentation was to become more extensive I feel the
> categories should be defined further and split into more documents.
>>
>> I to started with OE and failed to get a build to complete. Yocto got
>> me there first time, so it is already much better for a novice 'baker' !
>>
>> Some worked examples for 'how to do xxx' would also be nice. E.g.

I agree. We've oft talked about a Yocto Cookbook style document/wiki
page but nobody has yet gotten around to creating one.

The wiki is available and in an ideal world people would document things
as they've discovered them.

>>
>> 1) How do I configure the kernel ?
> This has been covered fairly extensively but a full worked example
> wouldn't go amiss.

http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#changing-the-kernel-configuration
?


>> 2) What do I need to do when I change my recipe to ensure that the
>> changes make it in to the image ?
> I don't know how to properly do this so +1
>> 3) How do I change and add startup scripts ?
> I read a lot about startup scripts to figure out how to do this the
> correct way - although it is more generic linux knowledge I believe an
> easy introduction to this with further reading wouldn't go amiss.

Nice cookbook candidate.

>> 4) How do I add data files to the image ?
> I would image these to go in with the software you are developing..
> however the fact I don't have a good answer may mean it needs addressing?

Cookbook candidate. Short answer - create a recipe which copies the
files over at do_install.
Long answer, I'd like to develop an inheritable bbclass to make this a
little simpler.

>> 5) How do I make sure dependencies (e.g. libraries) are included in
>> the image ? i.e. what do DEPENDS, RDEPENDS, etc. do.
> See 8

http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#ref-variables-glos

>> 6) How can I use a layer to hold my project files ?
> See 8

http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#usingpoky-changes

>> 7) Do I need to delete tmp/ and rebuild to ensure I've got a valid
>> project build configured ? (i.e. it doesn't rely on staged items that
>> don't build when I bitbake MyProject).
> Would be very good to get an example of how to ensure your build process
> is stable and will work every time from scratch.

I agree that this should be documented, short answer - no (you shouldn't
have to delete tmp/).

>> 8) How do I make my existing autobuild project in to a recipe ?
> *THIS.* I currently have no idea how to port my autobuild project coded
> using the Eclipse plugin to a recipe structure, couple this with 5 and 6
> and it would make a fantastic from 'start to finish' style manual.

http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#usingpoky-extend-addpkg-autotools

>> 9) How do I set / change the root password ?
> This seems fairly minor, is there a section in the wiki which could be
> devoted to things like this, rather than the faff of creating a new pdf
> etc.. this would also allow for the community to add tricks and tips in
> an easily accessible manner.

Cookbook candidate

Cheers,
Joshua
-- 
Joshua Lock
        Yocto Project "Johannes factotum"
        Intel Open Source Technology Centre

Re: Yocto usability questions

[Tom Zanussi]

On Fri, 2011-11-18 at 12:12 -0800, Joshua Lock wrote:
> 
> On 18/11/11 01:40, Jack Mitchell wrote:
> > On 17/11/2011 21:38, Chris Tapp wrote:
> >> On 16 Nov 2011, at 22:07, Jeff Osier-Mixon wrote:
> >>
> >>> Mark & everyone else listening:
> >>>
> >>> 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?
> >>>
> >>> 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?
> >>
> >> As another very experienced embedded systems developer who is
> >> relatively new to embedded linux I would say that documentation and
> >> worked examples are what I would really be after.
> >>
> > I am a fairly in-experienced embedded systems developer (fresh graduate,
> > 6 months real work exp) and have used Linux for a few years now and I
> > concur that written examples, tutorials if you will, would be a great idea.
> >> It can be really frustrating when you can't get something going
> >> because you don't understand the phrases / terminology that's being
> >> used and it isn't readily available via the documentation. I've seen
> >> quite a few posts on here relating to the documentation and it does
> >> look like good progress is being made. As someone said earlier in this
> >> thread, it would be good it run stuff through new (or relatively new)
> >> adopters to see if they can get the examples to work without a fight.
> >> I'm more than happy to help (and learn!).
> > It is very frustrating when you come to an issue that isn't documented,
> > however I have found the IRC an invaluable resource as well as this
> > mailing list. If documentation was to become more extensive I feel the
> > categories should be defined further and split into more documents.
> >>
> >> I to started with OE and failed to get a build to complete. Yocto got
> >> me there first time, so it is already much better for a novice 'baker' !
> >>
> >> Some worked examples for 'how to do xxx' would also be nice. E.g.
> 
> I agree. We've oft talked about a Yocto Cookbook style document/wiki
> page but nobody has yet gotten around to creating one.
> 
> The wiki is available and in an ideal world people would document things
> as they've discovered them.
> 
> >>
> >> 1) How do I configure the kernel ?
> > This has been covered fairly extensively but a full worked example
> > wouldn't go amiss.
> 
> http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#changing-the-kernel-configuration
> ?
> 
> 

In the way of a complete walk-through there's also this:

http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#dev-manual-bsp-appendix

Which I know works and is current because we went through the exercise
of making it so on this list a couple weeks ago ;-)

I believe it was based on this wiki guide I put together awhile ago:

https://wiki.yoctoproject.org/wiki/BKM:_starting_a_new_BSP

There are also a couple other 'transcripts' in the same location
designed to make it easy for someone to get started building and booting
a qemu image, real hardware, etc. and have some initial success (though
they may need to be updated again at this point).  There's also a small
section in there about configuring the kernel.

https://wiki.yoctoproject.org/wiki/BKM:_starting_a_new_BSP#Adding_new_options_and.2For_changing_kernel_code

A few days ago I put together a 'one stop shop' page pointing to those
docs and also adding a couple other things such as an 'FAQ' section
which is where I'd planned on continually adding answers to common
questions like those mentioned in this thread.  There's not much there
yet, and I haven't had time to verify anything, which is why I haven't
posted it.

https://wiki.yoctoproject.org/wiki/Yocto_BSP_One-Stop_Shop_(Documentation_Overview,_Getting_Started,_FAQs,_and_more)

The above started out BSP-specific to limit scope for my particular
needs, but it doesn't have to be.

Anyway, I think it's clear from this thread that some extensive
worked-through examples are needed, along with a wiki location that
collects FAQs or 'cookbook' items.

I'd be happy to work with anyone who wants to in helping getting
something like that started, whether it be a variation on the above, or
something from scratch, whatever.

In any case, it would be nice to have some concrete ideas on what would
make for a good walked-through example or set of examples...

Tom

[snip]

> Cheers,
> Joshua

Re: Yocto usability questions

[Osier-mixon, Jeffrey]

[-- Attachment #1: Type: text/plain, Size: 312 bytes --]

I have created a Cookbook page on the wiki at
https://wiki.yoctoproject.org/wiki/Cookbook

If you have tested procedures that work with the Yocto Project, please add
them to this page.

thanks!

-- 
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org

[-- Attachment #2: Type: text/html, Size: 560 bytes --]

Re: Yocto usability questions

[Chris Tapp]

[-- Attachment #1: Type: text/plain, Size: 414 bytes --]

On 18 Nov 2011, at 21:31, Osier-mixon, Jeffrey wrote:

> I have created a Cookbook page on the wiki at https://wiki.yoctoproject.org/wiki/Cookbook
>
> If you have tested procedures that work with the Yocto Project,  
> please add them to this page.

That'll teach me to keep quiet ;-)

I'll have a go at drafting something on startup scripts.

Chris Tapp

opensource@keylevel.com
www.keylevel.com


[-- Attachment #2: Type: text/html, Size: 1595 bytes --]

Re: Yocto usability questions

[Philip Balister]

On 11/18/2011 04:31 PM, Osier-mixon, Jeffrey wrote:
> I have created a Cookbook page on the wiki at
> https://wiki.yoctoproject.org/wiki/Cookbook
> 
> If you have tested procedures that work with the Yocto Project, please add
> them to this page.

We need to be really carefully to make sure wiki pages do not get
orphaned. Bad information on wiki's can also be a source of confusion.

I don't hate wiki's, just ones that bitrot.

Philip

Re: Yocto usability questions

[Osier-mixon, Jeffrey]

[-- Attachment #1: Type: text/plain, Size: 765 bytes --]

Good thing the project has a community manager to keep an eye on things
like that.  :D

On Fri, Nov 18, 2011 at 2:32 PM, Philip Balister <philip@balister.org>wrote:

> On 11/18/2011 04:31 PM, Osier-mixon, Jeffrey wrote:
> > I have created a Cookbook page on the wiki at
> > https://wiki.yoctoproject.org/wiki/Cookbook
> >
> > If you have tested procedures that work with the Yocto Project, please
> add
> > them to this page.
>
> We need to be really carefully to make sure wiki pages do not get
> orphaned. Bad information on wiki's can also be a source of confusion.
>
> I don't hate wiki's, just ones that bitrot.
>
> Philip
>



-- 
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org

[-- Attachment #2: Type: text/html, Size: 1316 bytes --]

Re: Yocto usability questions

[Rainer Koenig]

Hi Tom,

On 18.11.2011 21:54, Tom Zanussi wrote:

> I'd be happy to work with anyone who wants to in helping getting
> something like that started, whether it be a variation on the above, or
> something from scratch, whatever.

I just added a few FAQ entries to the wiki. I used the questions from
Chris Tapp and what came to my mind recently. And I used categories, so
that there is a hope for a sort of workflow. See

https://wiki.yoctoproject.org/wiki/Category:FAQ

for details.

> In any case, it would be nice to have some concrete ideas on what would
> make for a good walked-through example or set of examples...

Actually I'm still thinking if the wiki approach is helpful or if
someone (maybe even me) should write a book. ;-)

Regards
Rainer

Re: Yocto usability questions

[Tom Zanussi]

Hi Rainer,

On Tue, 2011-11-22 at 04:52 -0800, Rainer Koenig wrote:
> Hi Tom,
> 
> On 18.11.2011 21:54, Tom Zanussi wrote:
> 
> > I'd be happy to work with anyone who wants to in helping getting
> > something like that started, whether it be a variation on the above, or
> > something from scratch, whatever.
> 
> I just added a few FAQ entries to the wiki. I used the questions from
> Chris Tapp and what came to my mind recently. And I used categories, so
> that there is a hope for a sort of workflow. See
> 
> https://wiki.yoctoproject.org/wiki/Category:FAQ
> 
> for details.
> 

I really like this arrangement for the FAQs - it makes it much easier to
find relevant questions (even better if it were eventually categorized
even further e.g. by topic), and more importantly much easier to find
the questions that still need to be answered. ;-)

> > In any case, it would be nice to have some concrete ideas on what would
> > make for a good walked-through example or set of examples...
> 
> Actually I'm still thinking if the wiki approach is helpful or if
> someone (maybe even me) should write a book. ;-)
> 

To me, the wiki does make a lot sense for FAQs at least.  For other
things like examples or walk-throughs or longer articles on specific
topics, I kind of informally think of the wiki as a staging area for
stuff that could eventually go into one of the official Yocto manuals,
most likely the Development Manual, which seems to want to become the
kind of book you're thinking about, and this has already happened in a
couple cases.

If you're thinking more along the lines of something like an O'Reilly
book on Yocto, though, I'm guessing you could probably also find
volunteers for that too here.  ;-)

Tom

> Regards
> Rainer
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: Yocto usability questions

[Joshua Lock]

On 22/11/11 04:52, Rainer Koenig wrote:
> Hi Tom,
> 
> On 18.11.2011 21:54, Tom Zanussi wrote:
> 
>> I'd be happy to work with anyone who wants to in helping getting
>> something like that started, whether it be a variation on the above, or
>> something from scratch, whatever.
> 
> I just added a few FAQ entries to the wiki. I used the questions from
> Chris Tapp and what came to my mind recently. And I used categories, so
> that there is a hope for a sort of workflow. See
> 
> https://wiki.yoctoproject.org/wiki/Category:FAQ

Any feedback from you, Chris or anyone else as to whether the
documentation I linked to for some of those questions is sufficient? If
not I can work on enhancing that documentation.

Cheers,
Joshua
-- 
Joshua Lock
        Yocto Project "Johannes factotum"
        Intel Open Source Technology Centre

Re: Yocto usability questions

[Chris Tapp]

Hi Joshua,

On 22 Nov 2011, at 16:49, Joshua Lock wrote:
> On 22/11/11 04:52, Rainer Koenig wrote:
>> Hi Tom,
>>
>> On 18.11.2011 21:54, Tom Zanussi wrote:
>>
>>> I'd be happy to work with anyone who wants to in helping getting
>>> something like that started, whether it be a variation on the  
>>> above, or
>>> something from scratch, whatever.
>>
>> I just added a few FAQ entries to the wiki. I used the questions from
>> Chris Tapp and what came to my mind recently. And I used  
>> categories, so
>> that there is a hope for a sort of workflow. See
>>
>> https://wiki.yoctoproject.org/wiki/Category:FAQ
>
> Any feedback from you, Chris or anyone else as to whether the
> documentation I linked to for some of those questions is sufficient?  
> If
> not I can work on enhancing that documentation.


Yes, that looks good to me. I've already started a draft for the  
startup scripts FAQ under the https://wiki.yoctoproject.org/wiki/Cookbook 
  page that Jeffrey started at the end of last week. Where should it go?

PS Sorry it's taken a while to reply - Yocto is the night job, not the  
day one ;-)

Chris Tapp

opensource@keylevel.com
www.keylevel.com

Re: Yocto usability questions

[Joshua Lock]

On 22/11/11 13:03, Chris Tapp wrote:
> Hi Joshua,
>
> On 22 Nov 2011, at 16:49, Joshua Lock wrote:
>> On 22/11/11 04:52, Rainer Koenig wrote:
>>> Hi Tom,
>>>
>>> On 18.11.2011 21:54, Tom Zanussi wrote:
>>>
>>>> I'd be happy to work with anyone who wants to in helping getting
>>>> something like that started, whether it be a variation on the above, or
>>>> something from scratch, whatever.
>>>
>>> I just added a few FAQ entries to the wiki. I used the questions from
>>> Chris Tapp and what came to my mind recently. And I used categories, so
>>> that there is a hope for a sort of workflow. See
>>>
>>> https://wiki.yoctoproject.org/wiki/Category:FAQ
>>
>> Any feedback from you, Chris or anyone else as to whether the
>> documentation I linked to for some of those questions is sufficient? If
>> not I can work on enhancing that documentation.
>
>
> Yes, that looks good to me. I've already started a draft for the startup
> scripts FAQ under the https://wiki.yoctoproject.org/wiki/Cookbook page
> that Jeffrey started at the end of last week. Where should it go?

I like the format Rainer came up with, I'd go with that for now.

>
> PS Sorry it's taken a while to reply - Yocto is the night job, not the
> day one ;-)
>

No problem at all, I just wanted to make sure I'd provided enough 
information to keep you going before I ran off for a long turkey break :-)

Joshua
-- 
Joshua Lock
         Yocto Project "Johannes factotum"
         Intel Open Source Technology Centre

Re: Yocto usability questions

[Prasenjit Mahanti]

[-- Attachment #1: Type: text/plain, Size: 1368 bytes --]

I am getting permission denied error when trying to build in yacto build
environment.source code repository for Uboot I have kept in gitlab.com and
other build related dependencies I have kept in github.com. I have
downloaded(git clone) the built platform in my local machine. I made
changes in source code in gitlab.com.and try to fetch and build using
commit tag but getting permission error. If I doing the same in
github.com(keeping
source repository in githib.com and make changes) not facing nay issue.
want to know the solution

"Build failed error" posting from log file
DEBUG: Executing shell function do_compile
NOTE: make -j 4 CROSS_COMPILE=arm-poky-linux-gnueabi-
CC=arm-poky-linux-gnueabi-gcc
--sysroot=/home/cvp/prasenjit-bsp-platform/build/tmp/sysroots/prasenjit-novpek
mx6slnovpek_config
make: execvp:
/home/cvp/prasenjit-bsp-platform/build/tmp/work/prasenjit_novpek-poky-linux-gnueabi/u-boot-prasenjit-novpek/2014.07-r0/git/mkconfig:
Permission denied
Makefile:468: recipe for target 'mx6slnovpek_config' failed
make: *** [mx6slnovpek_config] Error 127
ERROR: oe_runmake failed
WARNING: exit code 1 from a shell command.
ERROR: Function failed: do_compile (log file is located at
/home/cvp/prasenjit-bsp-platform/build/tmp/work/prasenjit_novpek-poky-linux-gnueabi/u-boot-prasenjit-novpek/2014.07-r0/temp/log.do_compile.29185)

[-- Attachment #2: Type: text/html, Size: 1594 bytes --]