Re: [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 

Re: [yocto] 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
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] changing kernel config on a project built by Hob

[Darren Hart]

On 11/15/2011 11:57 AM, Joshua Lock wrote:
> Hi Jitendra,
> 
> On 11/11/11 11:37, Jitendra Shekhawat wrote:
>> Newbie here. I think I've looked at the relevant documents and couldn't
>> find how to do this.
>>
>> What is the procedure for doing a kernel 'make menuconfig' on hob
>> assisted projects?
>>
>> I created a simple project using following steps:
>> 1. source poky-edison-6.0/oe-init-build-env
>> 2. hob
>> 3. configuration under hob:
>>  - Machine: atom-pc
>>  - Base image: core-image-minimal 
>>  - Added openssh
>> 4. save the image as test.bb 
>> 5. Baked the image in hob
>> 6. Booted the result in Virtualbox after creating a bootable disk image,
>> etc.
>>
>> I need to now modify the kernel by adding CP210x USB/Serial converter
>> driver.
>>
>> What is the procedure for doing a 'make menuconfig' on this hob assisted
>> project?
> 
> Unfortunately we don't currently support modifying the kernel config via
> the hob GUI although it's certainly something we'd like to enable in the
> future.

Really what were talking about here is development of recipes versus
building them. Hob builds images - and offers some help configuring
which packages go into an image - but it doesn't modify the packages
themselves. "make menuconfig" is a development tool which makes
transient changes to the kernel build. In order for Hob (in its current
state anyway) to take advantage of those changes, they need to be made
permanent.  To do this, I suggest iterating on your kernel config using
the command line tools. Once you are happy with it, update the recipe to
use the new config, and then resume work with Hob. The final state of a
kernel config should be incorporated into the kernel recipes and source
repositories.

This isn't to say this process can't be improved, but such is the state
of things as they stand now.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] 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

opensou...@keylevel.com
www.keylevel.com

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

Re: [yocto] Help diagnosing a build failure involving ncurses, gettext, and eglibc

[Darren Hart]

On 11/03/2011 11:47 AM, Joshua Lock wrote:
> On 03/11/11 02:36, Jack Mitchell wrote:
>> On 03/11/2011 05:21, Darren Hart wrote:
>>>
>>> On 11/02/2011 10:16 PM, McClintock Matthew-B29882 wrote:
 On Thu, Nov 3, 2011 at 12:12 AM, Darren Hart 
 wrote:
> I came up with the following to ensure I have a log of every bitbake
> command I run along with some useful stats. Feel free to use it or
> flame it:
>
>
> #!/bin/bash
> TIMESTAMP=$(date -u "+%Y%m%d%H%M%S")
> LOG=$(mktemp --suffix=".log" bb-$TIMESTAMP-XXX)
> if [ -z "$LOG" ]; then
> echo "ERROR: failed to create log file"
> exit 1
> fi
>
> (
> echo "Start: $TIMESTAMP"
> echo ""
> /usr/bin/time 2>&1 -v bitbake $@
> echo ""
> echo "End: $(date -u '+%Y%m%d%H%M%S')"
> ) | tee $LOG
>
> echo "Logfile: $LOG"
 It would be nice if we had this as a selectable option in the bitbake
 wrapper somehow and it saved off logs to tmp/bitbake/logs/ or
 something appropriate.
>>> I was having similar thoughts just after having pressed send :)
>>>
>>> Given how annoying it is to not have the log when you forget to capture
>>> it, I think this might actually make a reasonable default. The important
>>> bits are of course already recorded in
>>> tmp/blah/blah/blah/temp/log.blah.PID... but the above serves almost like
>>> an index into the individual files. I'm all for logging it by default -
>>> as well as collecting summary stats. I don't know if the above is the
>>> best way to go about it - but a functional equivalent would be nice.
>>>
>>> For all I know something like this already exists and I just haven't
>>> stumbled upon it yet.
>>>
>>
>> I agree, something which actually logs what you are doing and how it was
>> done rather than just the output/error logging we have at the moment
>> would be a great addition. It would make it much easier to track errors
>> and help pin down bugs - especially if you have taken a long winded
>> route to get to a particular point.
> 
> Sounds like people would find this feature useful, can someone please
> file a bug report?
> 

http://bugzilla.yoctoproject.org/show_bug.cgi?id=1771

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] xserver-kdrive keyboard support

[Chris Tapp]

Do I need to do anything other than have:

PREFERED_PROVIDER-virtual/xserver = "xserver-kdrive"
XSERVER = "xserver-kdrive-fbdev"

to get a working keyboard under kdrive?

I've got a system that boots in to an application, but I can't use Ctrl 
+Alt+Backspace to terminate it...


Keyboard works just fine on console screens.

Chris Tapp

opensou...@keylevel.com
www.keylevel.com



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

Re: [yocto] Yocto usability questions

[Brian Duffy]

On Thu, Nov 17, 2011 at 4:38 PM, 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.
>
> 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
>
> opensou...@keylevel.com
> www.keylevel.com
>
>
> __**_
> yocto mailing list
> yocto@yoctoproject.org
> 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
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto usability questions

[Osier-mixon, Jeffrey]

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
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto