date:20120626


On 26 Jun 2012, at 02:36, Khem Raj wrote:

> On Mon, Jun 25, 2012 at 3:46 PM, Chris Tapp  wrote:
>> 
>> 
>> Well, that proves it's not the compiler. Still fails to boot, even though 
>> the toolchain that's supposed to work is 4.5.1. Does 32-bit / 64-bit host 
>> make a difference?
> 
> host should not matter although from my compiler experience I have
> seen few cases where hosts injects bugs into cross compiler which
> showed up on the target in compiled code but those cases were rare.

Yes, I've not really seen any issues in this area before.

> You should make sure that the compiler if the guys (who claim it works
> ) doesnt carry patches that are special.


The tree that holds the tools (https://github.com/raspberrypi/tools) doesn't 
seem to have any source, so I'm assuming it's unmodified. However, I've asked 
the question just incase...

One thing I have noticed is the kernel images I build are less than half the 
size of the 'official' ones.

Thanks for all the help you've given me on this :-)

Chris Tapp

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



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

Re: [yocto] Porting of specific Kernel/Driver into yocto.

On 26 Jun 2012, at 06:33, Om Prakash PAL wrote:

> Hi khem,
> on target, etc/ does not contain securetty.

What about /etc/inittab? Does this contain any references to tty0?

> Best Regards,
> Om Prakash Pal
> 
> From: Khem Raj [raj.k...@gmail.com]
> Sent: Monday, June 25, 2012 8:43 PM
> To: Om Prakash PAL
> Cc: Bruce Ashfield; yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
> 
> On Mon, Jun 25, 2012 at 7:12 AM, Om Prakash PAL
>  wrote:
>> Hi Bruce,
>> You can check the attached log.
>> 
>> It does not contain /dev/tty0..its /dev/ttyAMA2.
>> I am not able to get why is it opening /dev/tty0?.
> 
> whats there in /etc/securetty on target rfs ?
>> 
>> Best Regards,
>> Om Prakash Pal
>> 
>> -Original Message-
>> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
>> Sent: Monday, June 25, 2012 7:39 PM
>> To: Om Prakash PAL
>> Cc: Khem Raj; yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>> 
>> On 12-06-25 10:06 AM, Om Prakash PAL wrote:
>>> Hi Bruce,
>>> Yes,its arm board.
>>> Yes, I have verified and kernel bootline is properly passed to the kernel 
>>> by bootloader.
>> 
>> And does it (the bootline) contain /dev/tty0 ? .. because if things are
>> properly configured, it really shouldn't be trying to open it.
>> 
>> Cheers,
>> 
>> Bruce
>> 
>>> 
>>> Best Regards,
>>> Om Prakash Pal
>>> 
>>> -Original Message-
>>> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
>>> Sent: Monday, June 25, 2012 6:38 PM
>>> To: Om Prakash PAL
>>> Cc: Khem Raj; yocto@yoctoproject.org
>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>> 
>>> On 12-06-25 08:53 AM, Om Prakash PAL wrote:
 Hi Khem,
 I have build core-image-core. but still this Error:
 ==>
 11.165466] EXT3-fs (mmcblk0p1): mounted filesystem with writeback data 
 mode
 [   11.172668] VFS: Mounted root (ext3 filesystem) on device 179:1.
 [   11.179260] Freeing init memory: 316K
 INIT: version 2.88 booting
 Error Cannot open /dev/tty0: No such device or address
 mknod: /dev/console: File exists
 
 =>
 
 I have set SERIAL_CONSOLE="115200 ttyAMA2"  then why its taking /dev/tty0 
 ?.
>>> 
>>> I've lost some of the context on the board you are working with, but
>>> from ttyAMA2, I'm assuming it is an arm board. Have you verified that your
>>> bootloader can pass the kernel bootline properly to the kernel ? It is
>>> (unfortunately) fairly common that it isn't properly passed. If you
>>> modify your configuration to have a built in command line with your
>>> configuration, you may be able to get better setup to debug the
>>> problem.
>>> 
>>> Cheers,
>>> 
>>> Bruce
>>> 
 please help.
 
 Best Regards,
 Om Prakash Pal
 ___
 From: Khem Raj [raj.k...@gmail.com]
 Sent: Friday, June 22, 2012 11:18 AM
 To: Om Prakash PAL
 Cc: Gary Thomas; yocto@yoctoproject.org
 Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
 
 On Thu, Jun 21, 2012 at 10:37 PM, Om Prakash PAL
wrote:
> 
>>> and then console got  stuck.
>> 
>>> What do you have SERIAL_CONSOLE set to in your configuration?
>> 
>> I have set SERIAL_CONSOLE="115200 ttyAMA2". As we are using ttyAMA2 for 
>> console.
> 
>> What is your target device?  Do you really have /dev/ttyAMA2 serial 
>> port??.
> 
> Yes, I have /dev/ttyAMA2 serial port.
 
 Can you try using say poky/master and generate root file system and
 try that out ?
 another option is to try core-image-core
 ___
 yocto mailing list
 yocto@yoctoproject.org
 https://lists.yoctoproject.org/listinfo/yocto
>>> 
>> 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Chris Tapp

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



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

Re: [yocto] Porting of specific Kernel/Driver into yocto.

2012-06-26 Thread Om Prakash PAL

Hi Chris,
No, /etc/initab does not contain any reference to inittab.
please find the attched /etc/initab file for more information.

Best Regards,
Om Prakash Pal

=>

From: Chris Tapp [opensou...@keylevel.com]
Sent: Tuesday, June 26, 2012 12:52 PM
To: Om Prakash PAL
Cc: Khem Raj; yocto@yoctoproject.org
Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.

On 26 Jun 2012, at 06:33, Om Prakash PAL wrote:

> Hi khem,
> on target, etc/ does not contain securetty.

What about /etc/inittab? Does this contain any references to tty0?

> Best Regards,
> Om Prakash Pal
> 
> From: Khem Raj [raj.k...@gmail.com]
> Sent: Monday, June 25, 2012 8:43 PM
> To: Om Prakash PAL
> Cc: Bruce Ashfield; yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On Mon, Jun 25, 2012 at 7:12 AM, Om Prakash PAL
>  wrote:
>> Hi Bruce,
>> You can check the attached log.
>>
>> It does not contain /dev/tty0..its /dev/ttyAMA2.
>> I am not able to get why is it opening /dev/tty0?.
>
> whats there in /etc/securetty on target rfs ?
>>
>> Best Regards,
>> Om Prakash Pal
>>
>> -Original Message-
>> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
>> Sent: Monday, June 25, 2012 7:39 PM
>> To: Om Prakash PAL
>> Cc: Khem Raj; yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On 12-06-25 10:06 AM, Om Prakash PAL wrote:
>>> Hi Bruce,
>>> Yes,its arm board.
>>> Yes, I have verified and kernel bootline is properly passed to the kernel 
>>> by bootloader.
>>
>> And does it (the bootline) contain /dev/tty0 ? .. because if things are
>> properly configured, it really shouldn't be trying to open it.
>>
>> Cheers,
>>
>> Bruce
>>
>>>
>>> Best Regards,
>>> Om Prakash Pal
>>>
>>> -Original Message-
>>> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
>>> Sent: Monday, June 25, 2012 6:38 PM
>>> To: Om Prakash PAL
>>> Cc: Khem Raj; yocto@yoctoproject.org
>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>
>>> On 12-06-25 08:53 AM, Om Prakash PAL wrote:
 Hi Khem,
 I have build core-image-core. but still this Error:
 ==>
 11.165466] EXT3-fs (mmcblk0p1): mounted filesystem with writeback data 
 mode
 [   11.172668] VFS: Mounted root (ext3 filesystem) on device 179:1.
 [   11.179260] Freeing init memory: 316K
 INIT: version 2.88 booting
 Error Cannot open /dev/tty0: No such device or address
 mknod: /dev/console: File exists

 =>

 I have set SERIAL_CONSOLE="115200 ttyAMA2"  then why its taking /dev/tty0 
 ?.
>>>
>>> I've lost some of the context on the board you are working with, but
>>> from ttyAMA2, I'm assuming it is an arm board. Have you verified that your
>>> bootloader can pass the kernel bootline properly to the kernel ? It is
>>> (unfortunately) fairly common that it isn't properly passed. If you
>>> modify your configuration to have a built in command line with your
>>> configuration, you may be able to get better setup to debug the
>>> problem.
>>>
>>> Cheers,
>>>
>>> Bruce
>>>
 please help.

 Best Regards,
 Om Prakash Pal
 ___
 From: Khem Raj [raj.k...@gmail.com]
 Sent: Friday, June 22, 2012 11:18 AM
 To: Om Prakash PAL
 Cc: Gary Thomas; yocto@yoctoproject.org
 Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.

 On Thu, Jun 21, 2012 at 10:37 PM, Om Prakash PAL
wrote:
>
>>> and then console got  stuck.
>>
>>> What do you have SERIAL_CONSOLE set to in your configuration?
>>
>> I have set SERIAL_CONSOLE="115200 ttyAMA2". As we are using ttyAMA2 for 
>> console.
>
>> What is your target device?  Do you really have /dev/ttyAMA2 serial 
>> port??.
>
> Yes, I have /dev/ttyAMA2 serial port.

 Can you try using say poky/master and generate root file system and
 try that out ?
 another option is to try core-image-core
 ___
 yocto mailing list
 yocto@yoctoproject.org
 https://lists.yoctoproject.org/listinfo/yocto
>>>
>>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Chris Tapp

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





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

Re: [yocto] Porting of specific Kernel/Driver into yocto.

2012-06-26 Thread Om Prakash PAL

Hi Chris,
No, /etc/initab does not contain any reference to tty0(wrong typed in last 
mail).

Best Regards,
Om Prakash Pal

From: Chris Tapp [opensou...@keylevel.com]
Sent: Tuesday, June 26, 2012 12:52 PM
To: Om Prakash PAL
Cc: Khem Raj; yocto@yoctoproject.org
Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.

On 26 Jun 2012, at 06:33, Om Prakash PAL wrote:

> Hi khem,
> on target, etc/ does not contain securetty.

What about /etc/inittab? Does this contain any references to tty0?

> Best Regards,
> Om Prakash Pal
> 
> From: Khem Raj [raj.k...@gmail.com]
> Sent: Monday, June 25, 2012 8:43 PM
> To: Om Prakash PAL
> Cc: Bruce Ashfield; yocto@yoctoproject.org
> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>
> On Mon, Jun 25, 2012 at 7:12 AM, Om Prakash PAL
>  wrote:
>> Hi Bruce,
>> You can check the attached log.
>>
>> It does not contain /dev/tty0..its /dev/ttyAMA2.
>> I am not able to get why is it opening /dev/tty0?.
>
> whats there in /etc/securetty on target rfs ?
>>
>> Best Regards,
>> Om Prakash Pal
>>
>> -Original Message-
>> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
>> Sent: Monday, June 25, 2012 7:39 PM
>> To: Om Prakash PAL
>> Cc: Khem Raj; yocto@yoctoproject.org
>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>
>> On 12-06-25 10:06 AM, Om Prakash PAL wrote:
>>> Hi Bruce,
>>> Yes,its arm board.
>>> Yes, I have verified and kernel bootline is properly passed to the kernel 
>>> by bootloader.
>>
>> And does it (the bootline) contain /dev/tty0 ? .. because if things are
>> properly configured, it really shouldn't be trying to open it.
>>
>> Cheers,
>>
>> Bruce
>>
>>>
>>> Best Regards,
>>> Om Prakash Pal
>>>
>>> -Original Message-
>>> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
>>> Sent: Monday, June 25, 2012 6:38 PM
>>> To: Om Prakash PAL
>>> Cc: Khem Raj; yocto@yoctoproject.org
>>> Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.
>>>
>>> On 12-06-25 08:53 AM, Om Prakash PAL wrote:
 Hi Khem,
 I have build core-image-core. but still this Error:
 ==>
 11.165466] EXT3-fs (mmcblk0p1): mounted filesystem with writeback data 
 mode
 [   11.172668] VFS: Mounted root (ext3 filesystem) on device 179:1.
 [   11.179260] Freeing init memory: 316K
 INIT: version 2.88 booting
 Error Cannot open /dev/tty0: No such device or address
 mknod: /dev/console: File exists

 =>

 I have set SERIAL_CONSOLE="115200 ttyAMA2"  then why its taking /dev/tty0 
 ?.
>>>
>>> I've lost some of the context on the board you are working with, but
>>> from ttyAMA2, I'm assuming it is an arm board. Have you verified that your
>>> bootloader can pass the kernel bootline properly to the kernel ? It is
>>> (unfortunately) fairly common that it isn't properly passed. If you
>>> modify your configuration to have a built in command line with your
>>> configuration, you may be able to get better setup to debug the
>>> problem.
>>>
>>> Cheers,
>>>
>>> Bruce
>>>
 please help.

 Best Regards,
 Om Prakash Pal
 ___
 From: Khem Raj [raj.k...@gmail.com]
 Sent: Friday, June 22, 2012 11:18 AM
 To: Om Prakash PAL
 Cc: Gary Thomas; yocto@yoctoproject.org
 Subject: Re: [yocto] Porting of specific Kernel/Driver into yocto.

 On Thu, Jun 21, 2012 at 10:37 PM, Om Prakash PAL
wrote:
>
>>> and then console got  stuck.
>>
>>> What do you have SERIAL_CONSOLE set to in your configuration?
>>
>> I have set SERIAL_CONSOLE="115200 ttyAMA2". As we are using ttyAMA2 for 
>> console.
>
>> What is your target device?  Do you really have /dev/ttyAMA2 serial 
>> port??.
>
> Yes, I have /dev/ttyAMA2 serial port.

 Can you try using say poky/master and generate root file system and
 try that out ?
 another option is to try core-image-core
 ___
 yocto mailing list
 yocto@yoctoproject.org
 https://lists.yoctoproject.org/listinfo/yocto
>>>
>>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Chris Tapp

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



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

[yocto] how many meta-toolchain-* targets are there?


  something that could be cleared up a bit in the docs ... how many
toolchain-related targets are there?

  for instance, running bitbake suggests that common targets include
meta-toolchain and meta-toolchain-sdk.  on the other hand, the ADT
manual makes no reference to meta-toolchain-sdk but *does* mention
meta-toolchain-gmae (without explaining to the reader what that
represents but nonetheless recommends to the reader that if he needs
GMAE, he should build that, whereupon the poor reader is left
wondering what the heck GMAE is and whether it's important).

  and a search of the source shows a meta-toolchain-qte, for which i
can see no mention whatever in *any* of the docs.

  thoughts?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

[yocto] how does one use a prebuilt toolchain from the toolchain/ directory?


  it sounds like a trivial question whose answer should be easy to
find, but surprisingly, it isn't.  if a user wants to save all that
toolchain-building time and take advantage of an existing toolchain,
what to do?

  the ADT user's guide *sort of* addresses that, but in a somewhat
confusing way:

http://www.yoctoproject.org/docs/current/adt-manual/adt-manual.html

  first, the ADT guide, in section 2.1.2, talks about how to do this,
but only after the more complicated and involved recipe for using the
ADT installer.  this strikes me as backwards -- a set of alternatives
would make sense going from simplest to most complicated.  using a
prebuilt toolchain would seem to be the *first* thing that should be
explained.

  next, that section 2.1.2 in the ADT guide opens reasonably by
explaining how to find and download the appropriate toolchain and
then, for no apparent reason, takes this massive sidestep in a "Note"
to ask the reader to consider using bitbake to build it instead.  um
... no.  in the midst of explaining something really simple, it's
totally counter-productive to suddenly ask the reader to consider
something noticeably more complex and unnecessary in the context of
the current explanation.

  finally, after the Note is over, the instructions return to point
3., correctly telling the reader to unload the tarball at the root
directory, then vaguely referring to some "environment setup files"
without explaining what to do with them or when to run them or what
effect they'll have on the build process from then on. should one run
the appropriate env setup file *before* invoking oe-init-build-env?
after?  does it matter?

  so to clarify this issue, here's a set of questions to which i know
*some* of the answers and would like to know the rest.

1) i want to save buckets of time in my builds by using a pre-built
toolchain appropriate for my architecture.  can i always use one of
the toolchains at
http://downloads.yoctoproject.org/releases/yocto/yocto-1.2/toolchain/?
is there any downside to doing that?  if so, what?

2) do those pre-built toolchains always need to be installed under
/opt/poky?  it seems pretty obvious that they do, given that the
environment setup scripts hardcode references to /opt/poky.

3) can i install multiple toolchains at the same time?  it seems so --
the common native content in the toolchains seems identical so i don't
see any issue with having two or more toolchains installed at the same
time.

4) once i install a toolchain, how do i use it?  say i install the arm
toolchain, and want to build a beagleboard image.  at what point do i
source the arm toolchain environment setup file?  is that all it
takes?  will the bitbake build process automatically recognize what
i've done and use that toolchain?

  and so on, and so on.  thoughts?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

[yocto] the current yocto FAQ is pretty much valueless


  i mentioned this to scott rifenbark privately a few days ago, but i
figured i might as well antagonize a few people on the list by saying
it publicly -- the yocto FAQ as it stands is pretty much worthless.

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

  by way of explanation, i'll reproduce the first part of the superb
foreword in the subversion red book:

= start =

A bad Frequently Asked Questions (FAQ) sheet is one that is composed
not of the questions people actually ask, but of the questions the
FAQ's author wishes people would ask. Perhaps you've seen the type
before:

Q: How can I use Glorbosoft XYZ to maximize team productivity?

A: Many of our customers want to know how they can maximize
productivity through our patented office groupware innovations. The
answer is simple. First, click on the File menu, scroll down to
Increase Productivity, then…

The problem with such FAQs is that they are not, in a literal sense,
FAQs at all. No one ever called the tech support line and asked, “How
can we maximize productivity?” Rather, people asked highly specific
questions, such as “How can we change the calendaring system to send
reminders two days in advance instead of one?” and so on. But it's a
lot easier to make up imaginary Frequently Asked Questions than it is
to discover the real ones.

= end =

  in other words, a *good* FAQ might be:

"how can i use the yocto prebuilt toolchains to save build time?"

  a *bad* FAQ would be:

"Does the Yocto Project have a special governance model, or is it
managed as an open source project?"

  the kicker is that that last question is, in fact, in the yocto FAQ,
along with a number of other questions that have never been asked by
anyone in the history of the planet.  i chat about yocto with people
on a regular basis, and i can assure you, not a single one of them has
ever asked, "hey, rob, can you explain yocto's governance model?"

  no, what they ask is, "hey, rob, how can i add a single package to
an existing target?"  a question that, i should point out, is not
answered definitively in the existing docs *anywhere*.

  anyway, coffee is ready so i'm going to pour a cup and get back to
work.  you're now free to yell at me.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] the current yocto FAQ is pretty much valueless

2012-06-26 Thread Jack Mitchell


On 26/06/12 10:09, Robert P. J. Day wrote:


   snip...





   in other words, a *good* FAQ might be:

"how can i use the yocto prebuilt toolchains to save build time?"

   a *bad* FAQ would be:

"Does the Yocto Project have a special governance model, or is it
managed as an open source project?"

   the kicker is that that last question is, in fact, in the yocto FAQ,
along with a number of other questions that have never been asked by
anyone in the history of the planet.  i chat about yocto with people
on a regular basis, and i can assure you, not a single one of them has
ever asked, "hey, rob, can you explain yocto's governance model?"

   no, what they ask is, "hey, rob, how can i add a single package to
an existing target?"  a question that, i should point out, is not
answered definitively in the existing docs *anywhere*.


I would go as far as saying this is the most asked question on the list 
and definitely a good candidate for the FAQ.


Along with:

Why does package XYZ get built when XYZ has nothing to do with the image 
I imagine I am building.





   anyway, coffee is ready so i'm going to pour a cup and get back to
work.  you're now free to yell at me.

rday



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


--

  Jack Mitchell (j...@embed.me.uk)
  Embedded Systems Engineer
  http://www.embed.me.uk

--

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

Re: [yocto] the current yocto FAQ is pretty much valueless

2012-06-26 Thread Tomas Frydrych

On 26/06/12 10:09, Robert P. J. Day wrote:
> A bad Frequently Asked Questions (FAQ) sheet is one that is composed
> not of the questions people actually ask, but of the questions the
> FAQ's author wishes people would ask. Perhaps you've seen the type
> before:

Nice quote, but unfortunately based on the literal meaning the acronym
rather then insight into the function of a FAQ; asking the right
questions is far more important than finding answers ... ;-)

> "how can i use the yocto prebuilt toolchains to save build time?"

Perhaps your question is not asked frequently enough to merit inclusion
in a FAQ, or perhaps it's an a far too advanced topic for a FAQ?

>   a *bad* FAQ would be:
> 
> "Does the Yocto Project have a special governance model, or is it
> managed as an open source project?"

Just because you are not interested in the answer does not make it a
question you should think about ...

>   no, what they ask is, "hey, rob, how can i add a single package to
> an existing target?"  a question that, i should point out, is not
> answered definitively in the existing docs *anywhere*.

There are two correct answers to this: the first one is RTFM; the second
one is that if you want an explicit link to the section of the manual
that explains it to be included in the FAQ, you should write the
appropriate entry for the FAQ and contribute it instead of ranting on
the list.

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

Re: [yocto] the current yocto FAQ is pretty much valueless

On Tuesday 26 June 2012 05:09:34 Robert P. J. Day wrote:
>   in other words, a *good* FAQ might be:
> 
> "how can i use the yocto prebuilt toolchains to save build time?"
> 
>   a *bad* FAQ would be:
> 
> "Does the Yocto Project have a special governance model, or is it
> managed as an open source project?"
> 
>   the kicker is that that last question is, in fact, in the yocto FAQ,
> along with a number of other questions that have never been asked by
> anyone in the history of the planet.  i chat about yocto with people
> on a regular basis, and i can assure you, not a single one of them has
> ever asked, "hey, rob, can you explain yocto's governance model?"
> 
>   no, what they ask is, "hey, rob, how can i add a single package to
> an existing target?"  a question that, i should point out, is not
> answered definitively in the existing docs *anywhere*.

You bring up a valid point, but I think it might be worth mentioning that the 
current FAQ evolved from a much less technically-oriented version that was 
produced when the project launched. At that time some people *were* asking the 
kind of questions that you're deriding. I think there's still a section of the 
*non-technical* audience who are interested in answers to those questions.

I suggested to Scott R previously that it might be worth having a project FAQ 
(i.e., what is this project about, what is it intended to be used for etc.) 
and a separate technical FAQ which answers the kind of questions you are 
expecting and that we see often on the mailing list. I think one of the 
reasons that hasn't been done is that we're hoping to introduce a Q&A function 
on the website similar to StackOverflow, where everyone can participate but the 
most appropriate answers bubble up to the top. As yet this has not been 
implemented and I'm not sure when it will be, so it may still be worth looking 
into a static technical FAQ on the wiki until it is.

Scott, what do you think?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] the current yocto FAQ is pretty much valueless

On Tue, 26 Jun 2012, Paul Eggleton wrote:

> On Tuesday 26 June 2012 05:09:34 Robert P. J. Day wrote:
> >   in other words, a *good* FAQ might be:
> >
> > "how can i use the yocto prebuilt toolchains to save build time?"
> >
> >   a *bad* FAQ would be:
> >
> > "Does the Yocto Project have a special governance model, or is it
> > managed as an open source project?"
> >
> >   the kicker is that that last question is, in fact, in the yocto FAQ,
> > along with a number of other questions that have never been asked by
> > anyone in the history of the planet.  i chat about yocto with people
> > on a regular basis, and i can assure you, not a single one of them has
> > ever asked, "hey, rob, can you explain yocto's governance model?"
> >
> >   no, what they ask is, "hey, rob, how can i add a single package to
> > an existing target?"  a question that, i should point out, is not
> > answered definitively in the existing docs *anywhere*.
>
> You bring up a valid point, but I think it might be worth mentioning
> that the current FAQ evolved from a much less technically-oriented
> version that was produced when the project launched. At that time
> some people *were* asking the kind of questions that you're
> deriding. I think there's still a section of the *non-technical*
> audience who are interested in answers to those questions.

  i'm sure there's a place for those less technically-oriented
questions, but i will point out that on the main yocto docs page:

http://www.yoctoproject.org/documentation

you read:

"And, you view a list of commonly asked questions with their answers
by looking at the FAQ."

which, at the moment, simply isn't true.  in any event, that's my
$0.02 worth.  movin' on ...

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

[yocto] BSP for taskit stamp9g20

2012-06-26 Thread Markus Hubig

Hello @all,

as part of my bachelor thesis, I'm in the process of creating a custom
Linux OS
for the taskit Stamp9G20(a
small AT91SAM9G20 based CPU board). This is when
I came across the YoctoProject. Now I'm trying to build a BSP Layer for
this Board.

There are a lot of documentation out there, but I still miss the whole
picture ... :-(

This is what I've done so far:

$ yocto-bsp create stamp9g20 arm
-> kernel 3.2 [y]
-> new machine branch [y]
-> machine branch to base this BSP on
[standard/default/arm-versatile-926ejs]
-> Do you need SMP support? [n]
-> Which machine tuning would you like to use? [arm926ejs]
-> value for UBOOT_MACHINE [default: omap3_beagle_config]
-> UBOOT_ENTRYPOINT: [default: 0x80008000]
-> UBOOT_LOADADDRESS: [default: 0x80008000]
-> Do you need support for X? [n]
-> Does your BSP have a touchscreen? [default: n]
-> Does your BSP have a keyboard? [n]

(U-Boot stuff needs some adjustments but I save this for later ...)

Now I have a nice BSP layer for the Stamp9G20. Year! But whats the next
step? To get the right
kernel configuration for the stamp9g20 I can easily configure the kernel
with:

$ make ARCH=arm stamp9g20_defconfig

Here is what I "think" I have to do next. Please, please correct me if I
got it all wrong!

# make a bare clone
$ git clone --bare git://git.yoctoproject.org/linux-yocto-3.2
 linux-yocto-3.2.git

# make a *working clone* of the *bare clone*
$ git clone linux-yocto-3.2.git linux-yocto-3.2-work

# create a new branch based on arm-versatile-926ejs *inside my working clone
*
$ git checkout -b
yocto/standard/stamp9g20 remotes/origin/standard/default/arm-versatile-926ejs

# push the new branch back to the *bare clone*. Now I have a branch my
bsp-layer is based on?!
$ git push origin yocto/standard/stamp9g20:standard/default/stamp9g20

# check out the *meta branch* inside the *working clone*
$ git checkout -b meta-stamp9g20 remotes/origin/meta

# now I just copy the *arm-versatile-926ejs* dir to *stamp9g20* and rename
everything ...
$ cd meta/cfg/kernel-cache/bsp
$ cp -a arm-versatile-926ejs stamp9g20
$ cd stamp9g20
$ rename 's/arm-versatile-926ejs/stamp9g20/' *
$ sed -i 's/arm-versatile-926ejs/stamp9g20/' *

Now it get's in to the details. Since I have a working kernel config from "make
ARCH=arm stamp9g20_defconfig" I *think*
all I have to do is using the resulting .config file and put *parts of it*into
stamp9g20.cfg, right? Later more on this, but since
I'm more interested in the "big picture" I will leave these files as they
are for now.

# Add, commit and push the changes to the bare clone
$ git add stamp9g20
$ git commit -a -s
$ git push origin meta-stamp9g20:meta

# Now I change meta-stamp9g20/recipes-kernel/linux/linux-yocto_3.2.bbappend
# to point to my new branch
KBRANCH_stamp9g20 = "standard/default/stamp9g20"
YOCTO_KERNEL_EXTERNAL_BRANCH_stamp9g20  = "standard/default/stamp9g20"

# Clone poky-extras *into poky* ...
$ git clone git://git.yoctoproject.org/poky-extras poky-extras

#
edit poky-extras/meta-kernel-dev/recipes-kernel/linux/linux-yocto_3.2.bbappend
KSRC_linux_yocto_3_2 ?= "/home/mhubig/Development/linux-yocto-3.2.git"
SRC_URI =
"git://${KSRC_linux_yocto_3_2};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"

# Now lets try a build.
$ cd ~/poky
$ source oe-init-build-env

# Edit conf/bblayers.conf
BBLAYERS ?= " \
  /home/mhubig/Development/poky/meta \
  /home/mhubig/Development/poky/meta-yocto \
  /home/mhubig/Development/poky/meta-stamp9g20 \
  /home/mhubig/Development/poky/poky-extras/meta-kernel-dev \
  "

# Edit conf/local.conf
MACHINE ??= "stamp9g20"

and go ...

$ bitbake -c cleanall linux-yocto
$ bitbake -k core-image-minimal

This fails with a bunch of errors, all related to linux-yocto ...

$ bitbake -v -k linux-yocto
WARNING: Host distribution "Ubuntu 12.04 LTS" has not been validated with
this version of the build system; you may possibly experience unexpected
failures. It is recommended that you use a tested distribution.
Loading cache: 100%
|#|
ETA:  00:00:00
Loaded 1104 entries from dependency cache.
Parsing recipes: 100%
|###|
Time: 00:00:00
Parsing of 829 .bb files complete (827 cached, 2 parsed). 1105 targets, 37
skipped, 0 masked, 0 errors.

OE Build Configuration:
BB_VERSION= "1.15.1"
TARGET_ARCH   = "arm"
TARGET_OS = "linux-gnueabi"
MACHINE   = "stamp9g20"
DISTRO= "poky"
DISTRO_VERSION= "1.2"
TUNE_FEATURES = "armv5 dsp thumb arm926ejs"
TARGET_FPU= "soft"
meta
meta-yocto
meta-stamp9g20= "denzil:d20a24310eb43fed9a3f3e75752c9ad45a18cbe4"
meta-kernel-dev   = "master:42f1aba1c52da20edd65709152fec3529b3b516f"

NOTE: Resolving any missing task queue dependencies
NOTE: selecting pseudo-native to satisfy virtual/fakeroot-native due to
PREFERRED_PROVIDERS
NOTE: s

Re: [yocto] the current yocto FAQ is pretty much valueless

2012-06-26 Thread Koen Kooi


Op 26 jun. 2012, om 11:09 heeft Robert P. J. Day het volgende geschreven:

> 
>  i mentioned this to scott rifenbark privately a few days ago, but i
> figured i might as well antagonize a few people on the list by saying
> it publicly -- the yocto FAQ as it stands is pretty much worthless.
> 
>  https://wiki.yoctoproject.org/wiki/FAQ
> 
>  by way of explanation, i'll reproduce the first part of the superb
> foreword in the subversion red book:
> 
> = start =
> 
> A bad Frequently Asked Questions (FAQ) sheet is one that is composed
> not of the questions people actually ask, but of the questions the
> FAQ's author wishes people would ask. Perhaps you've seen the type
> before:
> 
> Q: How can I use Glorbosoft XYZ to maximize team productivity?
> 
> A: Many of our customers want to know how they can maximize
> productivity through our patented office groupware innovations. The
> answer is simple. First, click on the File menu, scroll down to
> Increase Productivity, then…
> 
> The problem with such FAQs is that they are not, in a literal sense,
> FAQs at all. No one ever called the tech support line and asked, “How
> can we maximize productivity?” Rather, people asked highly specific
> questions, such as “How can we change the calendaring system to send
> reminders two days in advance instead of one?” and so on. But it's a
> lot easier to make up imaginary Frequently Asked Questions than it is
> to discover the real ones.
> 
> = end =
> 
>  in other words, a *good* FAQ might be:
> 
> "how can i use the yocto prebuilt toolchains to save build time?"
> 
>  a *bad* FAQ would be:
> 
> "Does the Yocto Project have a special governance model, or is it
> managed as an open source project?"
> 
>  the kicker is that that last question is, in fact, in the yocto FAQ,
> along with a number of other questions that have never been asked by
> anyone in the history of the planet.  i chat about yocto with people
> on a regular basis, and i can assure you, not a single one of them has
> ever asked, "hey, rob, can you explain yocto's governance model?"
> 
>  no, what they ask is, "hey, rob, how can i add a single package to
> an existing target?"  a question that, i should point out, is not
> answered definitively in the existing docs *anywhere*.

I'm afraid you have fallen into the yocto trap of confusing the umbrella 
project with the buildsystem project under that umbrella. There's an easy way 
to find out, everytime you hear someone state 'yocto' you just ask:

 'Do you mean "yocto" or do you mean "poky"?'. 

The reaction to that can go a few ways and the follow up actions I recommend:

1) People don't get the question and/or don't know the difference between 
'yocto' and 'poky'. Pretend you have a nosebleed and walk away, fast
2) People say "Right, I meant the buildsystem, not the umbrella project" or 
"No, I really meant 'yocto' as the umbrella project". Continue the conversation.
3) People say "Koen put you up to this, didn't he?". You're most likely talking 
to Dave or Saul, buy them lunch :)

regards,

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

Re: [yocto] BSP for taskit stamp9g20


On 12-06-26 07:08 AM, Markus Hubig wrote:

Hello @all,

as part of my bachelor thesis, I'm in the process of creating a custom
Linux OS
for the taskit Stamp9G20
 (a small
AT91SAM9G20 based CPU board). This is when
I came across the YoctoProject. Now I'm trying to build a BSP Layer for
this Board.

There are a lot of documentation out there, but I still miss the whole
picture ... :-(

This is what I've done so far:


This is on master ? Yocto 1.2 ? Some other release ?



$ yocto-bsp create stamp9g20 arm
-> kernel 3.2 [y]
-> new machine branch [y]
-> machine branch to base this BSP on
[standard/default/arm-versatile-926ejs]
-> Do you need SMP support? [n]
-> Which machine tuning would you like to use? [arm926ejs]
-> value for UBOOT_MACHINE [default: omap3_beagle_config]
-> UBOOT_ENTRYPOINT: [default: 0x80008000]
-> UBOOT_LOADADDRESS: [default: 0x80008000]
-> Do you need support for X? [n]
-> Does your BSP have a touchscreen? [default: n]
-> Does your BSP have a keyboard? [n]

(U-Boot stuff needs some adjustments but I save this for later ...)

Now I have a nice BSP layer for the Stamp9G20. Year! But whats the next
step? To get the right
kernel configuration for the stamp9g20 I can easily configure the kernel
with:

$ make ARCH=arm stamp9g20_defconfig

Here is what I "think" I have to do next. Please, please correct me if I
got it all wrong!

# make a bare clone
$ git clone --bare git://git.yoctoproject.org/linux-yocto-3.2
 linux-yocto-3.2.git

# make a *working clone* of the *bare clone*
$ git clone linux-yocto-3.2.git linux-yocto-3.2-work

# create a new branch based on arm-versatile-926ejs *inside my working
clone*
$ git checkout -b yocto/standard/stamp9g20
remotes/origin/standard/default/arm-versatile-926ejs

# push the new branch back to the *bare clone*. Now I have a branch my
bsp-layer is based on?!
$ git push origin yocto/standard/stamp9g20:standard/default/stamp9g20

# check out the *meta branch* inside the *working clone*
$ git checkout -b meta-stamp9g20 remotes/origin/meta

# now I just copy the *arm-versatile-926ejs* dir to *stamp9g20* and
rename everything ...
$ cd meta/cfg/kernel-cache/bsp
$ cp -a arm-versatile-926ejs stamp9g20
$ cd stamp9g20
$ rename 's/arm-versatile-926ejs/stamp9g20/' *
$ sed -i 's/arm-versatile-926ejs/stamp9g20/' *

Now it get's in to the details. Since I have a working kernel config
from "make ARCH=arm stamp9g20_defconfig" I *think*
all I have to do is using the resulting .config file and put *parts of
it* into stamp9g20.cfg, right? Later more on this, but since
I'm more interested in the "big picture" I will leave these files as
they are for now.

# Add, commit and push the changes to the bare clone
$ git add stamp9g20
$ git commit -a -s
$ git push origin meta-stamp9g20:meta

# Now I change meta-stamp9g20/recipes-kernel/linux/linux-yocto_3.2.bbappend
# to point to my new branch
KBRANCH_stamp9g20 = "standard/default/stamp9g20"
YOCTO_KERNEL_EXTERNAL_BRANCH_stamp9g20 = "standard/default/stamp9g20"


You don't actually have an external branch, because you made the right
choice to use git to manage your BSP :P So you don't need this.



# Clone poky-extras *into poky* ...
$ git clone git://git.yoctoproject.org/poky-extras
 poky-extras

# edit
poky-extras/meta-kernel-dev/recipes-kernel/linux/linux-yocto_3.2.bbappend
KSRC_linux_yocto_3_2 ?= "/home/mhubig/Development/linux-yocto-3.2.git"
SRC_URI =
"git://${KSRC_linux_yocto_3_2};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"


This is all good, I run with this all day every day .. so far so good.



# Now lets try a build.
$ cd ~/poky
$ source oe-init-build-env

# Edit conf/bblayers.conf
BBLAYERS ?= " \
/home/mhubig/Development/poky/meta \
/home/mhubig/Development/poky/meta-yocto \
/home/mhubig/Development/poky/meta-stamp9g20 \
/home/mhubig/Development/poky/poky-extras/meta-kernel-dev \
"

# Edit conf/local.conf
MACHINE ??= "stamp9g20"

and go ...

$ bitbake -c cleanall linux-yocto
$ bitbake -k core-image-minimal

This fails with a bunch of errors, all related to linux-yocto ...

$ bitbake -v -k linux-yocto
WARNING: Host distribution "Ubuntu 12.04 LTS" has not been validated
with this version of the build system; you may possibly experience
unexpected failures. It is recommended that you use a tested distribution.
Loading cache: 100%
|#|
ETA: 00:00:00
Loaded 1104 entries from dependency cache.
Parsing recipes: 100%
|###|
Time: 00:00:00
Parsing of 829 .bb files complete (827 cached, 2 parsed). 1105 targets,
37 skipped, 0 masked, 0 errors.

OE Build Configuration:
BB_VERSION = "1.15.1"
TARGET_ARCH = "arm"
TARGET_OS = "linux-gnueabi"
MACHINE = "stamp9g20"
DISTRO = "poky"
DISTRO_VERSION = "1.2"
TUNE_FEATURES = "armv5 dsp thumb arm

[yocto] Fwd: BSP for taskit stamp9g20

2012-06-26 Thread Markus Hubig

On Tue, Jun 26, 2012 at 3:19 PM, Bruce Ashfield
 wrote:
>
> On 12-06-26 07:08 AM, Markus Hubig wrote:
>>
>> AT91SAM9G20 based CPU board). This is when I came across the YoctoProject.
>> Now I'm trying to build a BSP Layer for this Board.
>>
>> There are a lot of documentation out there, but I still miss the whole
>> picture ... :-(
>>
>> This is what I've done so far:
>
> This is on master ? Yocto 1.2 ? Some other release ?

I'm using Yocto 1.2 at the moment ...

>> $ yocto-bsp create stamp9g20 arm
>> -> kernel 3.2 [y]
>> -> new machine branch [y]
>> -> machine branch to base this BSP on [standard/default/arm-versatile-926ejs]
>> -> Do you need SMP support? [n]
>> -> Which machine tuning would you like to use? [arm926ejs]
>> -> value for UBOOT_MACHINE [default: omap3_beagle_config]
>> -> UBOOT_ENTRYPOINT: [default: 0x80008000]
>> -> UBOOT_LOADADDRESS: [default: 0x80008000]
>> -> Do you need support for X? [n]
>> -> Does your BSP have a touchscreen? [default: n]
>> -> Does your BSP have a keyboard? [n]
>>
>> (U-Boot stuff needs some adjustments but I save this for later ...)
>>
>> Now I have a nice BSP layer for the Stamp9G20. Year! But whats the next
>> step? To get the right kernel configuration for the stamp9g20 I can easily
>> configure the kernel with:
>>
>> $ make ARCH=arm stamp9g20_defconfig
>>
>> Here is what I "think" I have to do next. Please, please correct me if I
>> got it all wrong!
>>
>> # make a bare clone
>> $ git clone --bare git://git.yoctoproject.org/linux-yocto-3.2
>>  linux-yocto-3.2.git
>>
>> # make a *working clone* of the *bare clone*
>>
>> $ git clone linux-yocto-3.2.git linux-yocto-3.2-work
>>
>> # create a new branch based on arm-versatile-926ejs *inside my working
>> clone*
>>
>> $ git checkout -b yocto/standard/stamp9g20
>> remotes/origin/standard/default/arm-versatile-926ejs
>>
>> # push the new branch back to the *bare clone*. Now I have a branch my
>>
>> bsp-layer is based on?!
>> $ git push origin yocto/standard/stamp9g20:standard/default/stamp9g20
>>
>> # check out the *meta branch* inside the *working clone*
>>
>> $ git checkout -b meta-stamp9g20 remotes/origin/meta
>>
>> # now I just copy the *arm-versatile-926ejs* dir to *stamp9g20* and
>>
>> rename everything ...
>> $ cd meta/cfg/kernel-cache/bsp
>> $ cp -a arm-versatile-926ejs stamp9g20
>> $ cd stamp9g20
>> $ rename 's/arm-versatile-926ejs/stamp9g20/' *
>> $ sed -i 's/arm-versatile-926ejs/stamp9g20/' *
>>
>> Now it get's in to the details. Since I have a working kernel config
>> from "make ARCH=arm stamp9g20_defconfig" I *think*
>> all I have to do is using the resulting .config file and put *parts of
>> it* into stamp9g20.cfg, right? Later more on this, but since
>>
>> I'm more interested in the "big picture" I will leave these files as
>> they are for now.
>>
>> # Add, commit and push the changes to the bare clone
>> $ git add stamp9g20
>> $ git commit -a -s
>> $ git push origin meta-stamp9g20:meta
>>
>> # Now I change meta-stamp9g20/recipes-kernel/linux/linux-yocto_3.2.bbappend
>> # to point to my new branch
>> KBRANCH_stamp9g20 = "standard/default/stamp9g20"
>> YOCTO_KERNEL_EXTERNAL_BRANCH_stamp9g20 = "standard/default/stamp9g20"
>
>
> You don't actually have an external branch, because you made the right
> choice to use git to manage your BSP :P So you don't need this.

OK so I just remove the YOCTO_KERNEL_EXTERNAL_BRANCH_stamp9g20 line?

>>
>> # Clone poky-extras *into poky* ...
>>
>> $ git clone git://git.yoctoproject.org/poky-extras
>>  poky-extras
>>
>>
>> # edit
>> poky-extras/meta-kernel-dev/recipes-kernel/linux/linux-yocto_3.2.bbappend
>> KSRC_linux_yocto_3_2 ?= "/home/mhubig/Development/linux-yocto-3.2.git"
>> SRC_URI =
>> "git://${KSRC_linux_yocto_3_2};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
>
>
> This is all good, I run with this all day every day .. so far so good.

OK ...

>> [INFO]: checkpoint is already restored, nothing to do
>> + [ 0 -ne 0 ]
>> +
>> sccs=/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20-standard.scc
>> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.scc
>> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.cfg
>> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/user-config.cfg
>> /home/mhubig/Development/poky/meta-stamp9g20/recipes-kern
>> el/linux/files/user-patches.scc
>
> Aha. This is the problem, if you've decided to create a local repo,
> and a BSP branch, you don't need these files outside of the tree. But
> I'm betting these were created by the BSP tool .. hence the confusion
> as two methods are being mixed.

Aha this is hardly understandable from the Yocto Documentation ...

> If you stop using the local repository, and just use the BSP tool that
> should at least clarify the error messages and I can help more after
> that.

OK If I got this

Re: [yocto] BSP for taskit stamp9g20

On 12-06-26 09:49 AM, Markus Hubig wrote:

On Tue, Jun 26, 2012 at 3:19 PM, Bruce Ashfield
wrote:

On 12-06-26 07:08 AM, Markus Hubig wrote:

AT91SAM9G20 based CPU board). This is when I came across the YoctoProject.
Now I'm trying to build a BSP Layer for this Board.

There are a lot of documentation out there, but I still miss the whole
picture ... :-(

This is what I've done so far:

This is on master ? Yocto 1.2 ? Some other release ?

I'm using Yocto 1.2 at the moment ...

$ yocto-bsp create stamp9g20 arm
-> kernel 3.2 [y]
-> new machine branch [y]
-> machine branch to base this BSP on [standard/default/arm-versatile-926ejs]
-> Do you need SMP support? [n]
-> Which machine tuning would you like to use? [arm926ejs]
-> value for UBOOT_MACHINE [default: omap3_beagle_config]
-> UBOOT_ENTRYPOINT: [default: 0x80008000]
-> UBOOT_LOADADDRESS: [default: 0x80008000]
-> Do you need support for X? [n]
-> Does your BSP have a touchscreen? [default: n]
-> Does your BSP have a keyboard? [n]

(U-Boot stuff needs some adjustments but I save this for later ...)

Now I have a nice BSP layer for the Stamp9G20. Year! But whats the next
step? To get the right kernel configuration for the stamp9g20 I can easily
configure the kernel with:

$ make ARCH=arm stamp9g20_defconfig

Here is what I "think" I have to do next. Please, please correct me if I
got it all wrong!

# make a bare clone
$ git clone --bare git://git.yoctoproject.org/linux-yocto-3.2
linux-yocto-3.2.git

# make a *working clone* of the *bare clone*

$ git clone linux-yocto-3.2.git linux-yocto-3.2-work

# create a new branch based on arm-versatile-926ejs *inside my working
clone*

$ git checkout -b yocto/standard/stamp9g20
remotes/origin/standard/default/arm-versatile-926ejs

# push the new branch back to the *bare clone*. Now I have a branch my

bsp-layer is based on?!
$ git push origin yocto/standard/stamp9g20:standard/default/stamp9g20

# check out the *meta branch* inside the *working clone*

$ git checkout -b meta-stamp9g20 remotes/origin/meta

# now I just copy the *arm-versatile-926ejs* dir to *stamp9g20* and

rename everything ...
$ cd meta/cfg/kernel-cache/bsp
$ cp -a arm-versatile-926ejs stamp9g20
$ cd stamp9g20
$ rename 's/arm-versatile-926ejs/stamp9g20/' *
$ sed -i 's/arm-versatile-926ejs/stamp9g20/' *

Now it get's in to the details. Since I have a working kernel config
from "make ARCH=arm stamp9g20_defconfig" I *think*
all I have to do is using the resulting .config file and put *parts of
it* into stamp9g20.cfg, right? Later more on this, but since

I'm more interested in the "big picture" I will leave these files as
they are for now.

# Add, commit and push the changes to the bare clone
$ git add stamp9g20
$ git commit -a -s
$ git push origin meta-stamp9g20:meta

# Now I change meta-stamp9g20/recipes-kernel/linux/linux-yocto_3.2.bbappend
# to point to my new branch
KBRANCH_stamp9g20 = "standard/default/stamp9g20"
YOCTO_KERNEL_EXTERNAL_BRANCH_stamp9g20 = "standard/default/stamp9g20"

You don't actually have an external branch, because you made the right
choice to use git to manage your BSP :P So you don't need this.

OK so I just remove the YOCTO_KERNEL_EXTERNAL_BRANCH_stamp9g20 line?

# Clone poky-extras *into poky* ...

$ git clone git://git.yoctoproject.org/poky-extras
poky-extras

# edit
poky-extras/meta-kernel-dev/recipes-kernel/linux/linux-yocto_3.2.bbappend
KSRC_linux_yocto_3_2 ?= "/home/mhubig/Development/linux-yocto-3.2.git"
SRC_URI =
"git://${KSRC_linux_yocto_3_2};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"

This is all good, I run with this all day every day .. so far so good.

OK ...

[INFO]: checkpoint is already restored, nothing to do
+ [ 0 -ne 0 ]
+
sccs=/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20-standard.scc
/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.scc
/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.cfg
/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/user-config.cfg
/home/mhubig/Development/poky/meta-stamp9g20/recipes-kern
el/linux/files/user-patches.scc

Aha. This is the problem, if you've decided to create a local repo,
and a BSP branch, you don't need these files outside of the tree. But
I'm betting these were created by the BSP tool .. hence the confusion
as two methods are being mixed.

Aha this is hardly understandable from the Yocto Documentation ...

The BSP tool came after the sections that talk about local git trees,
so the docs are still debouncing a bit. They do need to make this
clear about the approaches, and that you should use one or the other
(and why).

If you stop using the local repository, and just use the BSP tool that
should at least clarify the error messages and I can help more after
that.

OK If I got this right, I don't ne

Re: [yocto] how many meta-toolchain-* targets are there?

2012-06-26 Thread Lu, Lianhao

toolchain-gmae is exactly the toolchain-sdk. qte is for embedded qt


"Robert P. J. Day" 编写：


  something that could be cleared up a bit in the docs ... how many
toolchain-related targets are there?

  for instance, running bitbake suggests that common targets include
meta-toolchain and meta-toolchain-sdk.  on the other hand, the ADT
manual makes no reference to meta-toolchain-sdk but *does* mention
meta-toolchain-gmae (without explaining to the reader what that
represents but nonetheless recommends to the reader that if he needs
GMAE, he should build that, whereupon the poor reader is left
wondering what the heck GMAE is and whether it's important).

  and a search of the source shows a meta-toolchain-qte, for which i
can see no mention whatever in *any* of the docs.

  thoughts?

rday

--


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
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] the current yocto FAQ is pretty much valueless

Thanks all - I enjoyed the rant.  The obvious point is that the FAQ needs 
attention.  A good thing to do would be if you have a question that you would 
like included in a "good" FAQ, such as the one mentioned by Robert about how to 
add a single package, put the question up on this list or actually submit a 
patch to the list.  As this little discussion thread noted, the FAQ was 
initially created when the project launched and I think much of it revolved 
around trying to answer the general "What the hell is Yocto anyway" question.  
I think we have moved into a "how do I do this" type of phase now and the FAQ 
should have more of those types of entries.  That is not to say that questions 
about the Yocto Project in general should be deleted.  

I will put some attention on the FAQ to try and inject a bit of value into it.  

Thanks, 
Scott

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Koen Kooi
Sent: Tuesday, June 26, 2012 4:30 AM
To: Robert P.J.Day
Cc: Yocto discussion list
Subject: Re: [yocto] the current yocto FAQ is pretty much valueless


Op 26 jun. 2012, om 11:09 heeft Robert P. J. Day het volgende geschreven:

> 
>  i mentioned this to scott rifenbark privately a few days ago, but i
> figured i might as well antagonize a few people on the list by saying
> it publicly -- the yocto FAQ as it stands is pretty much worthless.
> 
>  https://wiki.yoctoproject.org/wiki/FAQ
> 
>  by way of explanation, i'll reproduce the first part of the superb
> foreword in the subversion red book:
> 
> = start =
> 
> A bad Frequently Asked Questions (FAQ) sheet is one that is composed
> not of the questions people actually ask, but of the questions the
> FAQ's author wishes people would ask. Perhaps you've seen the type
> before:
> 
> Q: How can I use Glorbosoft XYZ to maximize team productivity?
> 
> A: Many of our customers want to know how they can maximize
> productivity through our patented office groupware innovations. The
> answer is simple. First, click on the File menu, scroll down to
> Increase Productivity, then...
> 
> The problem with such FAQs is that they are not, in a literal sense,
> FAQs at all. No one ever called the tech support line and asked, "How
> can we maximize productivity?" Rather, people asked highly specific
> questions, such as "How can we change the calendaring system to send
> reminders two days in advance instead of one?" and so on. But it's a
> lot easier to make up imaginary Frequently Asked Questions than it is
> to discover the real ones.
> 
> = end =
> 
>  in other words, a *good* FAQ might be:
> 
> "how can i use the yocto prebuilt toolchains to save build time?"
> 
>  a *bad* FAQ would be:
> 
> "Does the Yocto Project have a special governance model, or is it
> managed as an open source project?"
> 
>  the kicker is that that last question is, in fact, in the yocto FAQ,
> along with a number of other questions that have never been asked by
> anyone in the history of the planet.  i chat about yocto with people
> on a regular basis, and i can assure you, not a single one of them has
> ever asked, "hey, rob, can you explain yocto's governance model?"
> 
>  no, what they ask is, "hey, rob, how can i add a single package to
> an existing target?"  a question that, i should point out, is not
> answered definitively in the existing docs *anywhere*.

I'm afraid you have fallen into the yocto trap of confusing the umbrella 
project with the buildsystem project under that umbrella. There's an easy way 
to find out, everytime you hear someone state 'yocto' you just ask:

 'Do you mean "yocto" or do you mean "poky"?'. 

The reaction to that can go a few ways and the follow up actions I recommend:

1) People don't get the question and/or don't know the difference between 
'yocto' and 'poky'. Pretend you have a nosebleed and walk away, fast
2) People say "Right, I meant the buildsystem, not the umbrella project" or 
"No, I really meant 'yocto' as the umbrella project". Continue the conversation.
3) People say "Koen put you up to this, didn't he?". You're most likely talking 
to Dave or Saul, buy them lunch :)

regards,

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

[yocto] Yocto Development Manual Appendix B question

In the example in The Developement Manual v1.2 in Appendix B Section 
B.1.7, it states that you need to put in the statement:


KSRC_linux_yocto_3_2 ?= "/home/scottrif/linux-yocto-3.2.git"

into the appropriate .bbappend file way now in the poky-extra directory 
structure.  If I look at that file, |linux-yocto_3.2.bbappend| , I seen 
a SRC_URI line, immediately after our inserted KSRC statement, that is 
commented out:


# SRC_URI = 
"git://${KSRC_linux_yocto_3_2};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"


Should that line be uncommented or is the SRC_URI already defaulted 
somewhere to use the newly defined KSRC_linux_yocto_3_2 variable?


Jim A



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

Re: [yocto] Yocto Development Manual Appendix B question


On 12-06-26 10:52 AM, jfabernathy wrote:

In the example in The Developement Manual v1.2 in Appendix B Section
B.1.7, it states that you need to put in the statement:

KSRC_linux_yocto_3_2 ?="/home/scottrif/linux-yocto-3.2.git"

into the appropriate .bbappend file way now in the poky-extra directory
structure. If I look at that file, |linux-yocto_3.2.bbappend| , I seen a
SRC_URI line, immediately after our inserted KSRC statement, that is
commented out:

# SRC_URI =
"git://${KSRC_linux_yocto_3_2};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"

Should that line be uncommented or is the SRC_URI already defaulted
somewhere to use the newly defined KSRC_linux_yocto_3_2 variable?


It should be uncommented. I commented them by default, since the extras
repository is a bit of a collection ground. If they are uncommented, and
combined with the AUTOREV also set in the file, you are forced to fix
all files, versus just the one you want.

Cheers,

Bruce



Jim A





___
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] Yocto Development Manual Appendix B question

Bruce, 

Should the example note this?  Would it be best to specifically say to 
uncomment that SRC_URI line?

Scott

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Bruce Ashfield
Sent: Tuesday, June 26, 2012 7:54 AM
To: jfabernathy
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

On 12-06-26 10:52 AM, jfabernathy wrote:
> In the example in The Developement Manual v1.2 in Appendix B Section
> B.1.7, it states that you need to put in the statement:
>
> KSRC_linux_yocto_3_2 ?="/home/scottrif/linux-yocto-3.2.git"
>
> into the appropriate .bbappend file way now in the poky-extra directory
> structure. If I look at that file, |linux-yocto_3.2.bbappend| , I seen a
> SRC_URI line, immediately after our inserted KSRC statement, that is
> commented out:
>
> # SRC_URI =
> "git://${KSRC_linux_yocto_3_2};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
>
> Should that line be uncommented or is the SRC_URI already defaulted
> somewhere to use the newly defined KSRC_linux_yocto_3_2 variable?

It should be uncommented. I commented them by default, since the extras
repository is a bit of a collection ground. If they are uncommented, and
combined with the AUTOREV also set in the file, you are forced to fix
all files, versus just the one you want.

Cheers,

Bruce

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

___
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] BSP for taskit stamp9g20

2012-06-26 Thread Markus Hubig

Yhea! My first successful build!

Thank you very much!

On Tue, Jun 26, 2012 at 4:00 PM, Bruce Ashfield
 wrote:
> On 12-06-26 09:49 AM, Markus Hubig wrote:
>>
>> On Tue, Jun 26, 2012 at 3:19 PM, Bruce Ashfield
>>   wrote:
>>>
>>>
>>> On 12-06-26 07:08 AM, Markus Hubig wrote:


 AT91SAM9G20 based CPU board). This is when I came across the
 YoctoProject.
 Now I'm trying to build a BSP Layer for this Board.

 There are a lot of documentation out there, but I still miss the whole
 picture ... :-(

 This is what I've done so far:
>>>
>>>
>>> This is on master ? Yocto 1.2 ? Some other release ?
>>
>>
>> I'm using Yocto 1.2 at the moment ...
>>
 $ yocto-bsp create stamp9g20 arm
 ->  kernel 3.2 [y]
 ->  new machine branch [y]
 ->  machine branch to base this BSP on
 [standard/default/arm-versatile-926ejs]
 ->  Do you need SMP support? [n]
 ->  Which machine tuning would you like to use? [arm926ejs]
 ->  value for UBOOT_MACHINE [default: omap3_beagle_config]
 ->  UBOOT_ENTRYPOINT: [default: 0x80008000]
 ->  UBOOT_LOADADDRESS: [default: 0x80008000]
 ->  Do you need support for X? [n]
 ->  Does your BSP have a touchscreen? [default: n]
 ->  Does your BSP have a keyboard? [n]

 (U-Boot stuff needs some adjustments but I save this for later ...)

 Now I have a nice BSP layer for the Stamp9G20. Year! But whats the next
 step? To get the right kernel configuration for the stamp9g20 I can
 easily
 configure the kernel with:

 $ make ARCH=arm stamp9g20_defconfig

 Here is what I "think" I have to do next. Please, please correct me if I
 got it all wrong!

 # make a bare clone
 $ git clone --bare git://git.yoctoproject.org/linux-yocto-3.2
   linux-yocto-3.2.git

 # make a *working clone* of the *bare clone*

 $ git clone linux-yocto-3.2.git linux-yocto-3.2-work

 # create a new branch based on arm-versatile-926ejs *inside my working
 clone*

 $ git checkout -b yocto/standard/stamp9g20
 remotes/origin/standard/default/arm-versatile-926ejs

 # push the new branch back to the *bare clone*. Now I have a branch my

 bsp-layer is based on?!
 $ git push origin yocto/standard/stamp9g20:standard/default/stamp9g20

 # check out the *meta branch* inside the *working clone*

 $ git checkout -b meta-stamp9g20 remotes/origin/meta

 # now I just copy the *arm-versatile-926ejs* dir to *stamp9g20* and

 rename everything ...
 $ cd meta/cfg/kernel-cache/bsp
 $ cp -a arm-versatile-926ejs stamp9g20
 $ cd stamp9g20
 $ rename 's/arm-versatile-926ejs/stamp9g20/' *
 $ sed -i 's/arm-versatile-926ejs/stamp9g20/' *

 Now it get's in to the details. Since I have a working kernel config
 from "make ARCH=arm stamp9g20_defconfig" I *think*
 all I have to do is using the resulting .config file and put *parts of
 it* into stamp9g20.cfg, right? Later more on this, but since

 I'm more interested in the "big picture" I will leave these files as
 they are for now.

 # Add, commit and push the changes to the bare clone
 $ git add stamp9g20
 $ git commit -a -s
 $ git push origin meta-stamp9g20:meta

 # Now I change
 meta-stamp9g20/recipes-kernel/linux/linux-yocto_3.2.bbappend
 # to point to my new branch
 KBRANCH_stamp9g20 = "standard/default/stamp9g20"
 YOCTO_KERNEL_EXTERNAL_BRANCH_stamp9g20 = "standard/default/stamp9g20"
>>>
>>>
>>>
>>> You don't actually have an external branch, because you made the right
>>> choice to use git to manage your BSP :P So you don't need this.
>>
>>
>> OK so I just remove the YOCTO_KERNEL_EXTERNAL_BRANCH_stamp9g20 line?
>>

 # Clone poky-extras *into poky* ...

 $ git clone git://git.yoctoproject.org/poky-extras
   poky-extras


 # edit

 poky-extras/meta-kernel-dev/recipes-kernel/linux/linux-yocto_3.2.bbappend
 KSRC_linux_yocto_3_2 ?= "/home/mhubig/Development/linux-yocto-3.2.git"
 SRC_URI =

 "git://${KSRC_linux_yocto_3_2};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
>>>
>>>
>>>
>>> This is all good, I run with this all day every day .. so far so good.
>>
>>
>> OK ...
>>
 [INFO]: checkpoint is already restored, nothing to do
 + [ 0 -ne 0 ]
 +

 sccs=/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20-standard.scc

 /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.scc

 /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.cfg

 /home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/user-config.cfg
 /home/mhubig/Development/poky/meta-stamp9g20/recipes-kern
 el/linux/files

Re: [yocto] BSP for taskit stamp9g20


On 12-06-26 10:56 AM, Markus Hubig wrote:

Yhea! My first successful build!

Thank you very much!


nice! and no problem at all.

Cheers,

Bruce



On Tue, Jun 26, 2012 at 4:00 PM, Bruce Ashfield
  wrote:

On 12-06-26 09:49 AM, Markus Hubig wrote:


On Tue, Jun 26, 2012 at 3:19 PM, Bruce Ashfield
wrote:



On 12-06-26 07:08 AM, Markus Hubig wrote:



AT91SAM9G20 based CPU board). This is when I came across the
YoctoProject.
Now I'm trying to build a BSP Layer for this Board.

There are a lot of documentation out there, but I still miss the whole
picture ... :-(

This is what I've done so far:



This is on master ? Yocto 1.2 ? Some other release ?



I'm using Yocto 1.2 at the moment ...


$ yocto-bsp create stamp9g20 arm
->kernel 3.2 [y]
->new machine branch [y]
->machine branch to base this BSP on
[standard/default/arm-versatile-926ejs]
->Do you need SMP support? [n]
->Which machine tuning would you like to use? [arm926ejs]
->value for UBOOT_MACHINE [default: omap3_beagle_config]
->UBOOT_ENTRYPOINT: [default: 0x80008000]
->UBOOT_LOADADDRESS: [default: 0x80008000]
->Do you need support for X? [n]
->Does your BSP have a touchscreen? [default: n]
->Does your BSP have a keyboard? [n]

(U-Boot stuff needs some adjustments but I save this for later ...)

Now I have a nice BSP layer for the Stamp9G20. Year! But whats the next
step? To get the right kernel configuration for the stamp9g20 I can
easily
configure the kernel with:

$ make ARCH=arm stamp9g20_defconfig

Here is what I "think" I have to do next. Please, please correct me if I
got it all wrong!

# make a bare clone
$ git clone --bare git://git.yoctoproject.org/linux-yocto-3.2
linux-yocto-3.2.git

# make a *working clone* of the *bare clone*

$ git clone linux-yocto-3.2.git linux-yocto-3.2-work

# create a new branch based on arm-versatile-926ejs *inside my working
clone*

$ git checkout -b yocto/standard/stamp9g20
remotes/origin/standard/default/arm-versatile-926ejs

# push the new branch back to the *bare clone*. Now I have a branch my

bsp-layer is based on?!
$ git push origin yocto/standard/stamp9g20:standard/default/stamp9g20

# check out the *meta branch* inside the *working clone*

$ git checkout -b meta-stamp9g20 remotes/origin/meta

# now I just copy the *arm-versatile-926ejs* dir to *stamp9g20* and

rename everything ...
$ cd meta/cfg/kernel-cache/bsp
$ cp -a arm-versatile-926ejs stamp9g20
$ cd stamp9g20
$ rename 's/arm-versatile-926ejs/stamp9g20/' *
$ sed -i 's/arm-versatile-926ejs/stamp9g20/' *

Now it get's in to the details. Since I have a working kernel config
from "make ARCH=arm stamp9g20_defconfig" I *think*
all I have to do is using the resulting .config file and put *parts of
it* into stamp9g20.cfg, right? Later more on this, but since

I'm more interested in the "big picture" I will leave these files as
they are for now.

# Add, commit and push the changes to the bare clone
$ git add stamp9g20
$ git commit -a -s
$ git push origin meta-stamp9g20:meta

# Now I change
meta-stamp9g20/recipes-kernel/linux/linux-yocto_3.2.bbappend
# to point to my new branch
KBRANCH_stamp9g20 = "standard/default/stamp9g20"
YOCTO_KERNEL_EXTERNAL_BRANCH_stamp9g20 = "standard/default/stamp9g20"




You don't actually have an external branch, because you made the right
choice to use git to manage your BSP :P So you don't need this.



OK so I just remove the YOCTO_KERNEL_EXTERNAL_BRANCH_stamp9g20 line?



# Clone poky-extras *into poky* ...

$ git clone git://git.yoctoproject.org/poky-extras
poky-extras


# edit

poky-extras/meta-kernel-dev/recipes-kernel/linux/linux-yocto_3.2.bbappend
KSRC_linux_yocto_3_2 ?= "/home/mhubig/Development/linux-yocto-3.2.git"
SRC_URI =

"git://${KSRC_linux_yocto_3_2};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"




This is all good, I run with this all day every day .. so far so good.



OK ...


[INFO]: checkpoint is already restored, nothing to do
+ [ 0 -ne 0 ]
+

sccs=/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20-standard.scc

/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.scc

/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/stamp9g20.cfg

/home/mhubig/Development/poky/meta-stamp9g20/recipes-kernel/linux/files/user-config.cfg
/home/mhubig/Development/poky/meta-stamp9g20/recipes-kern
el/linux/files/user-patches.scc



Aha. This is the problem, if you've decided to create a local repo,
and a BSP branch, you don't need these files outside of the tree. But
I'm betting these were created by the BSP tool .. hence the confusion
as two methods are being mixed.



Aha this is hardly understandable from the Yocto Documentation ...



The BSP tool came after the sections that talk about local git trees,
so the docs are still debouncing a bit. They do need to make this
clear about th

Re: [yocto] the current yocto FAQ is pretty much valueless

On Tue, 26 Jun 2012, Rifenbark, Scott M wrote:

> Thanks all - I enjoyed the rant.  The obvious point is that the FAQ
> needs attention.  A good thing to do would be if you have a question
> that you would like included in a "good" FAQ, such as the one
> mentioned by Robert about how to add a single package, put the
> question up on this list or actually submit a patch to the list.
> As this little discussion thread noted, the FAQ was initially
> created when the project launched and I think much of it revolved
> around trying to answer the general "What the hell is Yocto anyway"
> question.  I think we have moved into a "how do I do this" type of
> phase now and the FAQ should have more of those types of entries.
> That is not to say that questions about the Yocto Project in general
> should be deleted.
>
> I will put some attention on the FAQ to try and inject a bit of
> value into it.

  since the ubiquitous reaction to complaining about something is
always, "don't just whine, do something about it," i'm doing that.
i've started a personal yocto FAQ, based on questions either i've
asked myself, or colleagues or clients have asked me, and i'm posting
them here (obviously a work in progress, typed in over the last hour):

http://www.crashcourse.ca/wiki/index.php/Yocto_FAQ

  i'm collecting questions that clearly belong in a "how do i do X?"
FAQ and, even if i don't know the answer, i'm still going to add the
question to remind me to *find* the answer.

  if you want to add a question and answer (or even just a question
because you *want* to know the answer), drop me a note -- that wiki is
not world-writable and never will be.

  anyway, back to work ...

rday

-- 

Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [yocto] how many meta-toolchain-* targets are there?

2012-06-26 Thread Khem Raj

On Tue, Jun 26, 2012 at 1:15 AM, Robert P. J. Day  wrote:
>
>  something that could be cleared up a bit in the docs ... how many
> toolchain-related targets are there?
>
>  for instance, running bitbake suggests that common targets include
> meta-toolchain and meta-toolchain-sdk.  on the other hand, the ADT
> manual makes no reference to meta-toolchain-sdk but *does* mention
> meta-toolchain-gmae (without explaining to the reader what that
> represents but nonetheless recommends to the reader that if he needs
> GMAE, he should build that, whereupon the poor reader is left
> wondering what the heck GMAE is and whether it's important).
>
>  and a search of the source shows a meta-toolchain-qte, for which i
> can see no mention whatever in *any* of the docs.
>
>  thoughts?


they should be documented I agree. meta-toolchain-gmae and
meta-toolchain-sdk are synonymous.


>
> rday
>
> --
>
> 
> Robert P. J. Day                                 Ottawa, Ontario, CANADA
>                        http://crashcourse.ca
>
> Twitter:                                       http://twitter.com/rpjday
> LinkedIn:                               http://ca.linkedin.com/in/rpjday
> 
> ___
> 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] the current yocto FAQ is pretty much valueless

2012-06-26 Thread Darren Hart



On 06/26/2012 03:09 AM, Paul Eggleton wrote:
> On Tuesday 26 June 2012 05:09:34 Robert P. J. Day wrote:
>>   in other words, a *good* FAQ might be:
>>
>> "how can i use the yocto prebuilt toolchains to save build time?"
>>
>>   a *bad* FAQ would be:
>>
>> "Does the Yocto Project have a special governance model, or is it
>> managed as an open source project?"
>>
>>   the kicker is that that last question is, in fact, in the yocto FAQ,
>> along with a number of other questions that have never been asked by
>> anyone in the history of the planet.  i chat about yocto with people
>> on a regular basis, and i can assure you, not a single one of them has
>> ever asked, "hey, rob, can you explain yocto's governance model?"
>>
>>   no, what they ask is, "hey, rob, how can i add a single package to
>> an existing target?"  a question that, i should point out, is not
>> answered definitively in the existing docs *anywhere*.
> 
> You bring up a valid point, but I think it might be worth mentioning that the 
> current FAQ evolved from a much less technically-oriented version that was 
> produced when the project launched. At that time some people *were* asking 
> the 
> kind of questions that you're deriding. I think there's still a section of 
> the 
> *non-technical* audience who are interested in answers to those questions.
> 
> I suggested to Scott R previously that it might be worth having a project FAQ 
> (i.e., what is this project about, what is it intended to be used for etc.) 
> and a separate technical FAQ which answers the kind of questions you are 
> expecting and that we see often on the mailing list. I think one of the 
> reasons that hasn't been done is that we're hoping to introduce a Q&A 
> function 
> on the website similar to StackOverflow, where everyone can participate but 
> the 
> most appropriate answers bubble up to the top. As yet this has not been 
> implemented and I'm not sure when it will be, so it may still be worth 
> looking 
> into a static technical FAQ on the wiki until it is.

Is "technical FAQ" == "How-Do-I pages" ?


-- 
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] how many meta-toolchain-* targets are there?

On Tue, 26 Jun 2012, Khem Raj wrote:

> On Tue, Jun 26, 2012 at 1:15 AM, Robert P. J. Day  
> wrote:
> >
> >  something that could be cleared up a bit in the docs ... how many
> > toolchain-related targets are there?
> >
> >  for instance, running bitbake suggests that common targets include
> > meta-toolchain and meta-toolchain-sdk.  on the other hand, the ADT
> > manual makes no reference to meta-toolchain-sdk but *does* mention
> > meta-toolchain-gmae (without explaining to the reader what that
> > represents but nonetheless recommends to the reader that if he needs
> > GMAE, he should build that, whereupon the poor reader is left
> > wondering what the heck GMAE is and whether it's important).
> >
> >  and a search of the source shows a meta-toolchain-qte, for which i
> > can see no mention whatever in *any* of the docs.
> >
> >  thoughts?
>
> they should be documented I agree. meta-toolchain-gmae and
> meta-toolchain-sdk are synonymous.

  i was about to make that very point.  :-)

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] the current yocto FAQ is pretty much valueless

Great!  Thanks Robert.

-Original Message-
From: Robert P. J. Day [mailto:rpj...@crashcourse.ca] 
Sent: Tuesday, June 26, 2012 8:46 AM
To: Rifenbark, Scott M
Cc: Koen Kooi; Yocto discussion list
Subject: RE: [yocto] the current yocto FAQ is pretty much valueless

On Tue, 26 Jun 2012, Rifenbark, Scott M wrote:

> Thanks all - I enjoyed the rant.  The obvious point is that the FAQ
> needs attention.  A good thing to do would be if you have a question
> that you would like included in a "good" FAQ, such as the one
> mentioned by Robert about how to add a single package, put the
> question up on this list or actually submit a patch to the list.
> As this little discussion thread noted, the FAQ was initially
> created when the project launched and I think much of it revolved
> around trying to answer the general "What the hell is Yocto anyway"
> question.  I think we have moved into a "how do I do this" type of
> phase now and the FAQ should have more of those types of entries.
> That is not to say that questions about the Yocto Project in general
> should be deleted.
>
> I will put some attention on the FAQ to try and inject a bit of
> value into it.

  since the ubiquitous reaction to complaining about something is
always, "don't just whine, do something about it," i'm doing that.
i've started a personal yocto FAQ, based on questions either i've
asked myself, or colleagues or clients have asked me, and i'm posting
them here (obviously a work in progress, typed in over the last hour):

http://www.crashcourse.ca/wiki/index.php/Yocto_FAQ

  i'm collecting questions that clearly belong in a "how do i do X?"
FAQ and, even if i don't know the answer, i'm still going to add the
question to remind me to *find* the answer.

  if you want to add a question and answer (or even just a question
because you *want* to know the answer), drop me a note -- that wiki is
not world-writable and never will be.

  anyway, back to work ...

rday

-- 

Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [yocto] Yocto Development Manual Appendix B question


On 12-06-26 10:56 AM, Rifenbark, Scott M wrote:

Bruce,

Should the example note this?  Would it be best to specifically say to 
uncomment that SRC_URI line?


It's worth noting, and I can make sure that the comments in the
recipes reflect this as well. My comments within the individual
bbappends may not be noticed, or may be less obvious when you look
at the recipes-kernel as a whole.

Cheers,

Bruce



Scott

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Bruce Ashfield
Sent: Tuesday, June 26, 2012 7:54 AM
To: jfabernathy
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

On 12-06-26 10:52 AM, jfabernathy wrote:

In the example in The Developement Manual v1.2 in Appendix B Section
B.1.7, it states that you need to put in the statement:

KSRC_linux_yocto_3_2 ?="/home/scottrif/linux-yocto-3.2.git"

into the appropriate .bbappend file way now in the poky-extra directory
structure. If I look at that file, |linux-yocto_3.2.bbappend| , I seen a
SRC_URI line, immediately after our inserted KSRC statement, that is
commented out:

# SRC_URI =
"git://${KSRC_linux_yocto_3_2};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"

Should that line be uncommented or is the SRC_URI already defaulted
somewhere to use the newly defined KSRC_linux_yocto_3_2 variable?


It should be uncommented. I commented them by default, since the extras
repository is a bit of a collection ground. If they are uncommented, and
combined with the AUTOREV also set in the file, you are forced to fix
all files, versus just the one you want.

Cheers,

Bruce



Jim A





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


___
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] Yocto Development Manual Appendix B question


On 06/26/2012 10:56 AM, Rifenbark, Scott M wrote:

Bruce,

Should the example note this?  Would it be best to specifically say to 
uncomment that SRC_URI line?

Scott
I think some text needs to be added. I uncommented the SRC_URI line and 
I still fail building the image.  The failure is related to kernel tools:


ERROR: kern-tools-native: md5 data is not matching for 
file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d843f43d2e22b0d91a6fee
ERROR: kern-tools-native: The new md5 checksum is 
d8d1d729a70cd5f52972f8884b80743d

ERROR: kern-tools-native: Check if the license information has changed in
ERROR: Licensing Error: LIC_FILES_CHKSUM does not match, please fix
ERROR: Function failed: do_qa_configure


Jim A


-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Bruce Ashfield
Sent: Tuesday, June 26, 2012 7:54 AM
To: jfabernathy
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

On 12-06-26 10:52 AM, jfabernathy wrote:

In the example in The Developement Manual v1.2 in Appendix B Section
B.1.7, it states that you need to put in the statement:

KSRC_linux_yocto_3_2 ?="/home/scottrif/linux-yocto-3.2.git"

into the appropriate .bbappend file way now in the poky-extra directory
structure. If I look at that file, |linux-yocto_3.2.bbappend| , I seen a
SRC_URI line, immediately after our inserted KSRC statement, that is
commented out:

# SRC_URI =
"git://${KSRC_linux_yocto_3_2};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"

Should that line be uncommented or is the SRC_URI already defaulted
somewhere to use the newly defined KSRC_linux_yocto_3_2 variable?

It should be uncommented. I commented them by default, since the extras
repository is a bit of a collection ground. If they are uncommented, and
combined with the AUTOREV also set in the file, you are forced to fix
all files, versus just the one you want.

Cheers,

Bruce


Jim A





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

___
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] Yocto Development Manual Appendix B question


On 12-06-26 12:00 PM, jfabernathy wrote:

On 06/26/2012 10:56 AM, Rifenbark, Scott M wrote:

Bruce,

Should the example note this? Would it be best to specifically say to
uncomment that SRC_URI line?

Scott

I think some text needs to be added. I uncommented the SRC_URI line and
I still fail building the image. The failure is related to kernel tools:

ERROR: kern-tools-native: md5 data is not matching for
file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d843f43d2e22b0d91a6fee

ERROR: kern-tools-native: The new md5 checksum is
d8d1d729a70cd5f52972f8884b80743d
ERROR: kern-tools-native: Check if the license information has changed in
ERROR: Licensing Error: LIC_FILES_CHKSUM does not match, please fix
ERROR: Function failed: do_qa_configure


This one is actually fixed on master, but poky-extras .. is just that
'extra', so this may still be alive in that repo.

This wouldn't need to be documented, since it's a bug/issue, and not
something that would persist.

What release are you pairing poky extras with ? I can always create a
branch to make sure they are consistent.

Cheers,

Bruce




Jim A


-Original Message-
From: yocto-boun...@yoctoproject.org
[mailto:yocto-boun...@yoctoproject.org] On Behalf Of Bruce Ashfield
Sent: Tuesday, June 26, 2012 7:54 AM
To: jfabernathy
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

On 12-06-26 10:52 AM, jfabernathy wrote:

In the example in The Developement Manual v1.2 in Appendix B Section
B.1.7, it states that you need to put in the statement:

KSRC_linux_yocto_3_2 ?="/home/scottrif/linux-yocto-3.2.git"

into the appropriate .bbappend file way now in the poky-extra directory
structure. If I look at that file, |linux-yocto_3.2.bbappend| , I seen a
SRC_URI line, immediately after our inserted KSRC statement, that is
commented out:

# SRC_URI =
"git://${KSRC_linux_yocto_3_2};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"


Should that line be uncommented or is the SRC_URI already defaulted
somewhere to use the newly defined KSRC_linux_yocto_3_2 variable?

It should be uncommented. I commented them by default, since the extras
repository is a bit of a collection ground. If they are uncommented, and
combined with the AUTOREV also set in the file, you are forced to fix
all files, versus just the one you want.

Cheers,

Bruce


Jim A





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

___
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] the current yocto FAQ is pretty much valueless

On Tuesday 26 June 2012 08:46:45 Darren Hart wrote:
> On 06/26/2012 03:09 AM, Paul Eggleton wrote:
> > I suggested to Scott R previously that it might be worth having a project
> > FAQ (i.e., what is this project about, what is it intended to be used for
> > etc.) and a separate technical FAQ which answers the kind of questions
> > you are expecting and that we see often on the mailing list. I think one
> > of the reasons that hasn't been done is that we're hoping to introduce a
> > Q&A function on the website similar to StackOverflow, where everyone can
> > participate but the most appropriate answers bubble up to the top. As yet
> > this has not been implemented and I'm not sure when it will be, so it may
> > still be worth looking into a static technical FAQ on the wiki until it
> > is.
> 
> Is "technical FAQ" == "How-Do-I pages" ?

Kind of, except most but not all FAQ questions really fit into "How do I...".

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto Development Manual Appendix B question


On 06/26/2012 12:04 PM, Bruce Ashfield wrote:

On 12-06-26 12:00 PM, jfabernathy wrote:

On 06/26/2012 10:56 AM, Rifenbark, Scott M wrote:

Bruce,

Should the example note this? Would it be best to specifically say to
uncomment that SRC_URI line?

Scott

I think some text needs to be added. I uncommented the SRC_URI line and
I still fail building the image. The failure is related to kernel tools:

ERROR: kern-tools-native: md5 data is not matching for
file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d843f43d2e22b0d91a6fee 



ERROR: kern-tools-native: The new md5 checksum is
d8d1d729a70cd5f52972f8884b80743d
ERROR: kern-tools-native: Check if the license information has 
changed in

ERROR: Licensing Error: LIC_FILES_CHKSUM does not match, please fix
ERROR: Function failed: do_qa_configure


This one is actually fixed on master, but poky-extras .. is just that
'extra', so this may still be alive in that repo.

This wouldn't need to be documented, since it's a bug/issue, and not
something that would persist.

What release are you pairing poky extras with ? I can always create a
branch to make sure they are consistent.



I was using Denzil because the snapshot noted in the example does not 
exist.  So there is another doc issue.


I can always test on Master, but the docs need to be update to reflect 
something that will work to completion without errors, IMHO.


Jim A


Cheers,

Bruce




Jim A


-Original Message-
From: yocto-boun...@yoctoproject.org
[mailto:yocto-boun...@yoctoproject.org] On Behalf Of Bruce Ashfield
Sent: Tuesday, June 26, 2012 7:54 AM
To: jfabernathy
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

On 12-06-26 10:52 AM, jfabernathy wrote:

In the example in The Developement Manual v1.2 in Appendix B Section
B.1.7, it states that you need to put in the statement:

KSRC_linux_yocto_3_2 ?="/home/scottrif/linux-yocto-3.2.git"

into the appropriate .bbappend file way now in the poky-extra 
directory
structure. If I look at that file, |linux-yocto_3.2.bbappend| , I 
seen a

SRC_URI line, immediately after our inserted KSRC statement, that is
commented out:

# SRC_URI =
"git://${KSRC_linux_yocto_3_2};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta" 




Should that line be uncommented or is the SRC_URI already defaulted
somewhere to use the newly defined KSRC_linux_yocto_3_2 variable?

It should be uncommented. I commented them by default, since the extras
repository is a bit of a collection ground. If they are uncommented, 
and

combined with the AUTOREV also set in the file, you are forced to fix
all files, versus just the one you want.

Cheers,

Bruce


Jim A





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

___
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] the current yocto FAQ is pretty much valueless

On Tuesday 26 June 2012 11:45:50 Robert P. J. Day wrote:
>   since the ubiquitous reaction to complaining about something is
> always, "don't just whine, do something about it," i'm doing that.
> i've started a personal yocto FAQ, based on questions either i've
> asked myself, or colleagues or clients have asked me, and i'm posting
> them here (obviously a work in progress, typed in over the last hour):
> 
> http://www.crashcourse.ca/wiki/index.php/Yocto_FAQ
> 
>   i'm collecting questions that clearly belong in a "how do i do X?"
> FAQ and, even if i don't know the answer, i'm still going to add the
> question to remind me to *find* the answer.

Just looking at that page, a couple of items spring to mind:

1) Why are you pointing people to the prefile/postfile options in preference to 
just putting the "common, personal configuration" in local.conf?

2) Your IMAGE_INSTALL_append example needs a leading space in the string or it 
will almost certainly not work (or at least, it will only work when there's 
already a trailing space in the value of IMAGE_INSTALL).

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto Development Manual Appendix B question


On 12-06-26 12:11 PM, jfabernathy wrote:

On 06/26/2012 12:04 PM, Bruce Ashfield wrote:

On 12-06-26 12:00 PM, jfabernathy wrote:

On 06/26/2012 10:56 AM, Rifenbark, Scott M wrote:

Bruce,

Should the example note this? Would it be best to specifically say to
uncomment that SRC_URI line?

Scott

I think some text needs to be added. I uncommented the SRC_URI line and
I still fail building the image. The failure is related to kernel tools:

ERROR: kern-tools-native: md5 data is not matching for
file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d843f43d2e22b0d91a6fee


ERROR: kern-tools-native: The new md5 checksum is
d8d1d729a70cd5f52972f8884b80743d
ERROR: kern-tools-native: Check if the license information has
changed in
ERROR: Licensing Error: LIC_FILES_CHKSUM does not match, please fix
ERROR: Function failed: do_qa_configure


This one is actually fixed on master, but poky-extras .. is just that
'extra', so this may still be alive in that repo.

This wouldn't need to be documented, since it's a bug/issue, and not
something that would persist.

What release are you pairing poky extras with ? I can always create a
branch to make sure they are consistent.



I was using Denzil because the snapshot noted in the example does not
exist. So there is another doc issue.


Aha. In this case, we could note that the poky-extras repo branch should
match the main repository branch .. and I could ensure that meta-kernel-dev
works in that configuration.

That's likely the right solution, rather than forcing you to switch to
master (unless you want to :)

Cheers,

Bruce



I can always test on Master, but the docs need to be update to reflect
something that will work to completion without errors, IMHO.

Jim A


Cheers,

Bruce




Jim A


-Original Message-
From: yocto-boun...@yoctoproject.org
[mailto:yocto-boun...@yoctoproject.org] On Behalf Of Bruce Ashfield
Sent: Tuesday, June 26, 2012 7:54 AM
To: jfabernathy
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

On 12-06-26 10:52 AM, jfabernathy wrote:

In the example in The Developement Manual v1.2 in Appendix B Section
B.1.7, it states that you need to put in the statement:

KSRC_linux_yocto_3_2 ?="/home/scottrif/linux-yocto-3.2.git"

into the appropriate .bbappend file way now in the poky-extra
directory
structure. If I look at that file, |linux-yocto_3.2.bbappend| , I
seen a
SRC_URI line, immediately after our inserted KSRC statement, that is
commented out:

# SRC_URI =
"git://${KSRC_linux_yocto_3_2};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"



Should that line be uncommented or is the SRC_URI already defaulted
somewhere to use the newly defined KSRC_linux_yocto_3_2 variable?

It should be uncommented. I commented them by default, since the extras
repository is a bit of a collection ground. If they are uncommented,
and
combined with the AUTOREV also set in the file, you are forced to fix
all files, versus just the one you want.

Cheers,

Bruce


Jim A





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

___
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] the current yocto FAQ is pretty much valueless

On Tue, 26 Jun 2012, Paul Eggleton wrote:

> On Tuesday 26 June 2012 11:45:50 Robert P. J. Day wrote:
> >   since the ubiquitous reaction to complaining about something is
> > always, "don't just whine, do something about it," i'm doing that.
> > i've started a personal yocto FAQ, based on questions either i've
> > asked myself, or colleagues or clients have asked me, and i'm posting
> > them here (obviously a work in progress, typed in over the last hour):
> >
> > http://www.crashcourse.ca/wiki/index.php/Yocto_FAQ
> >
> >   i'm collecting questions that clearly belong in a "how do i do X?"
> > FAQ and, even if i don't know the answer, i'm still going to add the
> > question to remind me to *find* the answer.
>
> Just looking at that page, a couple of items spring to mind:
>
> 1) Why are you pointing people to the prefile/postfile options in preference 
> to
> just putting the "common, personal configuration" in local.conf?

  i thought that was the technique for centralizing personal config
preferences that you *didn't* want to manually copy into every
local.conf file you created.  if you add that personal content into
each local.conf, then of course you don't need those options.

> 2) Your IMAGE_INSTALL_append example needs a leading space in the string or it
> will almost certainly not work (or at least, it will only work when there's
> already a trailing space in the value of IMAGE_INSTALL).

  whoops, quite so.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [yocto] Yocto Development Manual Appendix B question

This is a good point.  In looking at the example it does not say what branch 
you should be dealing with for poky-extras.

-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] 
Sent: Tuesday, June 26, 2012 9:24 AM
To: jfabernathy
Cc: Rifenbark, Scott M; yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

On 12-06-26 12:11 PM, jfabernathy wrote:
> On 06/26/2012 12:04 PM, Bruce Ashfield wrote:
>> On 12-06-26 12:00 PM, jfabernathy wrote:
>>> On 06/26/2012 10:56 AM, Rifenbark, Scott M wrote:
 Bruce,

 Should the example note this? Would it be best to specifically say to
 uncomment that SRC_URI line?

 Scott
>>> I think some text needs to be added. I uncommented the SRC_URI line and
>>> I still fail building the image. The failure is related to kernel tools:
>>>
>>> ERROR: kern-tools-native: md5 data is not matching for
>>> file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d843f43d2e22b0d91a6fee
>>>
>>>
>>> ERROR: kern-tools-native: The new md5 checksum is
>>> d8d1d729a70cd5f52972f8884b80743d
>>> ERROR: kern-tools-native: Check if the license information has
>>> changed in
>>> ERROR: Licensing Error: LIC_FILES_CHKSUM does not match, please fix
>>> ERROR: Function failed: do_qa_configure
>>
>> This one is actually fixed on master, but poky-extras .. is just that
>> 'extra', so this may still be alive in that repo.
>>
>> This wouldn't need to be documented, since it's a bug/issue, and not
>> something that would persist.
>>
>> What release are you pairing poky extras with ? I can always create a
>> branch to make sure they are consistent.
>>
>
> I was using Denzil because the snapshot noted in the example does not
> exist. So there is another doc issue.

Aha. In this case, we could note that the poky-extras repo branch should
match the main repository branch .. and I could ensure that meta-kernel-dev
works in that configuration.

That's likely the right solution, rather than forcing you to switch to
master (unless you want to :)

Cheers,

Bruce

>
> I can always test on Master, but the docs need to be update to reflect
> something that will work to completion without errors, IMHO.
>
> Jim A
>
>> Cheers,
>>
>> Bruce
>>
>>>
>>>
>>> Jim A
>>>
 -Original Message-
 From: yocto-boun...@yoctoproject.org
 [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Bruce Ashfield
 Sent: Tuesday, June 26, 2012 7:54 AM
 To: jfabernathy
 Cc: yocto@yoctoproject.org
 Subject: Re: [yocto] Yocto Development Manual Appendix B question

 On 12-06-26 10:52 AM, jfabernathy wrote:
> In the example in The Developement Manual v1.2 in Appendix B Section
> B.1.7, it states that you need to put in the statement:
>
> KSRC_linux_yocto_3_2 ?="/home/scottrif/linux-yocto-3.2.git"
>
> into the appropriate .bbappend file way now in the poky-extra
> directory
> structure. If I look at that file, |linux-yocto_3.2.bbappend| , I
> seen a
> SRC_URI line, immediately after our inserted KSRC statement, that is
> commented out:
>
> # SRC_URI =
> "git://${KSRC_linux_yocto_3_2};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
>
>
>
> Should that line be uncommented or is the SRC_URI already defaulted
> somewhere to use the newly defined KSRC_linux_yocto_3_2 variable?
 It should be uncommented. I commented them by default, since the extras
 repository is a bit of a collection ground. If they are uncommented,
 and
 combined with the AUTOREV also set in the file, you are forced to fix
 all files, versus just the one you want.

 Cheers,

 Bruce

> Jim A
>
>
>
>
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
 ___
 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] Yocto Development Manual Appendix B question


On 12-06-26 12:26 PM, Rifenbark, Scott M wrote:

This is a good point.  In looking at the example it does not say what branch 
you should be dealing with for poky-extras.


And I'm configuring a test right now and will create a denzil
branch, once I see it works.

Cheers,

Bruce



-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, June 26, 2012 9:24 AM
To: jfabernathy
Cc: Rifenbark, Scott M; yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

On 12-06-26 12:11 PM, jfabernathy wrote:

On 06/26/2012 12:04 PM, Bruce Ashfield wrote:

On 12-06-26 12:00 PM, jfabernathy wrote:

On 06/26/2012 10:56 AM, Rifenbark, Scott M wrote:

Bruce,

Should the example note this? Would it be best to specifically say to
uncomment that SRC_URI line?

Scott

I think some text needs to be added. I uncommented the SRC_URI line and
I still fail building the image. The failure is related to kernel tools:

ERROR: kern-tools-native: md5 data is not matching for
file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d843f43d2e22b0d91a6fee


ERROR: kern-tools-native: The new md5 checksum is
d8d1d729a70cd5f52972f8884b80743d
ERROR: kern-tools-native: Check if the license information has
changed in
ERROR: Licensing Error: LIC_FILES_CHKSUM does not match, please fix
ERROR: Function failed: do_qa_configure


This one is actually fixed on master, but poky-extras .. is just that
'extra', so this may still be alive in that repo.

This wouldn't need to be documented, since it's a bug/issue, and not
something that would persist.

What release are you pairing poky extras with ? I can always create a
branch to make sure they are consistent.



I was using Denzil because the snapshot noted in the example does not
exist. So there is another doc issue.


Aha. In this case, we could note that the poky-extras repo branch should
match the main repository branch .. and I could ensure that meta-kernel-dev
works in that configuration.

That's likely the right solution, rather than forcing you to switch to
master (unless you want to :)

Cheers,

Bruce



I can always test on Master, but the docs need to be update to reflect
something that will work to completion without errors, IMHO.

Jim A


Cheers,

Bruce




Jim A


-Original Message-
From: yocto-boun...@yoctoproject.org
[mailto:yocto-boun...@yoctoproject.org] On Behalf Of Bruce Ashfield
Sent: Tuesday, June 26, 2012 7:54 AM
To: jfabernathy
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

On 12-06-26 10:52 AM, jfabernathy wrote:

In the example in The Developement Manual v1.2 in Appendix B Section
B.1.7, it states that you need to put in the statement:

KSRC_linux_yocto_3_2 ?="/home/scottrif/linux-yocto-3.2.git"

into the appropriate .bbappend file way now in the poky-extra
directory
structure. If I look at that file, |linux-yocto_3.2.bbappend| , I
seen a
SRC_URI line, immediately after our inserted KSRC statement, that is
commented out:

# SRC_URI =
"git://${KSRC_linux_yocto_3_2};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"



Should that line be uncommented or is the SRC_URI already defaulted
somewhere to use the newly defined KSRC_linux_yocto_3_2 variable?

It should be uncommented. I commented them by default, since the extras
repository is a bit of a collection ground. If they are uncommented,
and
combined with the AUTOREV also set in the file, you are forced to fix
all files, versus just the one you want.

Cheers,

Bruce


Jim A





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

___
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] Yocto Development Manual Appendix B question

I am going to run through the B.1 example verbatim from the "current" version 
of the manual and see what happens.

Scott

-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] 
Sent: Tuesday, June 26, 2012 9:28 AM
To: Rifenbark, Scott M
Cc: jfabernathy; yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

On 12-06-26 12:26 PM, Rifenbark, Scott M wrote:
> This is a good point.  In looking at the example it does not say what branch 
> you should be dealing with for poky-extras.

And I'm configuring a test right now and will create a denzil
branch, once I see it works.

Cheers,

Bruce

>
> -Original Message-
> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
> Sent: Tuesday, June 26, 2012 9:24 AM
> To: jfabernathy
> Cc: Rifenbark, Scott M; yocto@yoctoproject.org
> Subject: Re: [yocto] Yocto Development Manual Appendix B question
>
> On 12-06-26 12:11 PM, jfabernathy wrote:
>> On 06/26/2012 12:04 PM, Bruce Ashfield wrote:
>>> On 12-06-26 12:00 PM, jfabernathy wrote:
 On 06/26/2012 10:56 AM, Rifenbark, Scott M wrote:
> Bruce,
>
> Should the example note this? Would it be best to specifically say to
> uncomment that SRC_URI line?
>
> Scott
 I think some text needs to be added. I uncommented the SRC_URI line and
 I still fail building the image. The failure is related to kernel tools:

 ERROR: kern-tools-native: md5 data is not matching for
 file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d843f43d2e22b0d91a6fee


 ERROR: kern-tools-native: The new md5 checksum is
 d8d1d729a70cd5f52972f8884b80743d
 ERROR: kern-tools-native: Check if the license information has
 changed in
 ERROR: Licensing Error: LIC_FILES_CHKSUM does not match, please fix
 ERROR: Function failed: do_qa_configure
>>>
>>> This one is actually fixed on master, but poky-extras .. is just that
>>> 'extra', so this may still be alive in that repo.
>>>
>>> This wouldn't need to be documented, since it's a bug/issue, and not
>>> something that would persist.
>>>
>>> What release are you pairing poky extras with ? I can always create a
>>> branch to make sure they are consistent.
>>>
>>
>> I was using Denzil because the snapshot noted in the example does not
>> exist. So there is another doc issue.
>
> Aha. In this case, we could note that the poky-extras repo branch should
> match the main repository branch .. and I could ensure that meta-kernel-dev
> works in that configuration.
>
> That's likely the right solution, rather than forcing you to switch to
> master (unless you want to :)
>
> Cheers,
>
> Bruce
>
>>
>> I can always test on Master, but the docs need to be update to reflect
>> something that will work to completion without errors, IMHO.
>>
>> Jim A
>>
>>> Cheers,
>>>
>>> Bruce
>>>


 Jim A

> -Original Message-
> From: yocto-boun...@yoctoproject.org
> [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Bruce Ashfield
> Sent: Tuesday, June 26, 2012 7:54 AM
> To: jfabernathy
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Yocto Development Manual Appendix B question
>
> On 12-06-26 10:52 AM, jfabernathy wrote:
>> In the example in The Developement Manual v1.2 in Appendix B Section
>> B.1.7, it states that you need to put in the statement:
>>
>> KSRC_linux_yocto_3_2 ?="/home/scottrif/linux-yocto-3.2.git"
>>
>> into the appropriate .bbappend file way now in the poky-extra
>> directory
>> structure. If I look at that file, |linux-yocto_3.2.bbappend| , I
>> seen a
>> SRC_URI line, immediately after our inserted KSRC statement, that is
>> commented out:
>>
>> # SRC_URI =
>> "git://${KSRC_linux_yocto_3_2};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
>>
>>
>>
>> Should that line be uncommented or is the SRC_URI already defaulted
>> somewhere to use the newly defined KSRC_linux_yocto_3_2 variable?
> It should be uncommented. I commented them by default, since the extras
> repository is a bit of a collection ground. If they are uncommented,
> and
> combined with the AUTOREV also set in the file, you are forced to fix
> all files, versus just the one you want.
>
> Cheers,
>
> Bruce
>
>> Jim A
>>
>>
>>
>>
>>
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
> ___
> 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] the current yocto FAQ is pretty much valueless

On Tuesday 26 June 2012 12:26:28 Robert P. J. Day wrote:
>   i thought that was the technique for centralizing personal config
> preferences that you *didn't* want to manually copy into every
> local.conf file you created.  if you add that personal content into
> each local.conf, then of course you don't need those options.

I guess it depends on what you mean by "personal content". Certain settings 
are really part of distro policy and if you're finding that you're setting them 
all the time for all of the builds that you're doing, it would make more sense 
to create a distro layer that sets them - then it's simply a matter of 
ensuring that layer is added to your bblayers.conf and you set DISTRO as 
appropriate.

AFAIK the command line options in question were added to allow frontends to 
inject configuration into bitbake rather than something the user would normally 
use directly.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] the current yocto FAQ is pretty much valueless

2012-06-26 Thread Tomas Frydrych

On 26/06/12 17:06, Paul Eggleton wrote:
> On Tuesday 26 June 2012 08:46:45 Darren Hart wrote:
>> On 06/26/2012 03:09 AM, Paul Eggleton wrote:
>>> I suggested to Scott R previously that it might be worth having a project
>>> FAQ (i.e., what is this project about, what is it intended to be used for
>>> etc.) and a separate technical FAQ which answers the kind of questions
>>> you are expecting and that we see often on the mailing list. I think one
>>> of the reasons that hasn't been done is that we're hoping to introduce a
>>> Q&A function on the website similar to StackOverflow, where everyone can
>>> participate but the most appropriate answers bubble up to the top. As yet
>>> this has not been implemented and I'm not sure when it will be, so it may
>>> still be worth looking into a static technical FAQ on the wiki until it
>>> is.
>>
>> Is "technical FAQ" == "How-Do-I pages" ?
> 
> Kind of, except most but not all FAQ questions really fit into "How do I...".

Kooen's cheeky point is worth keeping in mind though; the Yocto naming
semantics is not very helpful ;-) Specifically most of the questions
being asked on the Yocto list are about Poky, not Yocto, followed by
questions about meta-yocto, not Yocto-project. Many of the questions
being asked on the list are readily answered by googling for 'Poky
Manual', but clearly very few people understand the Yocto project
semantics enough to do this ...

Tomas


> 
> Cheers,
> Paul
> 

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

Re: [yocto] Yocto weekly bug trend charts -- WW25

2012-06-26 Thread Stewart, David C

Thanks for adding the annotation to the WDD chart on how you compute it. :-)


>-Original Message-
>From: yocto-boun...@yoctoproject.org [mailto:yocto-
>boun...@yoctoproject.org] On Behalf Of Xu, Jiajun
>Sent: Monday, June 25, 2012 9:33 PM
>To: yocto@yoctoproject.org
>Subject: [yocto] Yocto weekly bug trend charts -- WW25
>
>Hi all,
>   This is the weekly bug trend for WW25. WDD number and Open Bug
>number keep flat with WW24, as 1101 and 225. Bug status of WW25 could be
>found on https://wiki.yoctoproject.org/wiki/Yocto_Bug_Trend.
>
>Best Regards,
>Jiajun
>
>
>___
>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] the current yocto FAQ is pretty much valueless

On Tue, 26 Jun 2012, Paul Eggleton wrote:

> On Tuesday 26 June 2012 12:26:28 Robert P. J. Day wrote:
> >   i thought that was the technique for centralizing personal config
> > preferences that you *didn't* want to manually copy into every
> > local.conf file you created.  if you add that personal content into
> > each local.conf, then of course you don't need those options.
>
> I guess it depends on what you mean by "personal content". Certain
> settings are really part of distro policy and if you're finding that
> you're setting them all the time for all of the builds that you're
> doing, it would make more sense to create a distro layer that sets
> them - then it's simply a matter of ensuring that layer is added to
> your bblayers.conf and you set DISTRO as appropriate.
>
> AFAIK the command line options in question were added to allow
> frontends to inject configuration into bitbake rather than something
> the user would normally use directly.

  ok, that makes sense.  but would it also make sense for bitbake to
perhaps support another option that *does* allow personal content to,
say, be effectively appended to one's local.conf.  for instance, every
single local.conf i create immediately gets this added to the end:

SOURCE_MIRROR_URL ?= "file:///home/rpjday/dl/"
INHERIT += "own-mirrors"
BB_GENERATE_MIRROR_TARBALLS = "1"
# BB_NO_NETWORK = "1"

  is there a simpler way to do that?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [yocto] the current yocto FAQ is pretty much valueless

On Tue, 26 Jun 2012, Tomas Frydrych wrote:

> Kooen's cheeky point is worth keeping in mind though; the Yocto
> naming semantics is not very helpful ;-) Specifically most of the
> questions being asked on the Yocto list are about Poky, not Yocto,
> followed by questions about meta-yocto, not Yocto-project. Many of
> the questions being asked on the list are readily answered by
> googling for 'Poky Manual', but clearly very few people understand
> the Yocto project semantics enough to do this ...

  and if you want major industry players to take yocto seriously, the
last thing you want to do is answer their heartfelt pleas for
assistance with, "i'm sorry, that's technically not a yocto question,
you should try another mailing list."

  even if you're technically correct, that sort of conversation is not
going to end well.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [yocto] the current yocto FAQ is pretty much valueless

On Tuesday 26 June 2012 12:51:15 Robert P. J. Day wrote:
> On Tue, 26 Jun 2012, Paul Eggleton wrote:
> > On Tuesday 26 June 2012 12:26:28 Robert P. J. Day wrote:
> > >   i thought that was the technique for centralizing personal config
> > > 
> > > preferences that you *didn't* want to manually copy into every
> > > local.conf file you created.  if you add that personal content into
> > > each local.conf, then of course you don't need those options.
> > 
> > I guess it depends on what you mean by "personal content". Certain
> > settings are really part of distro policy and if you're finding that
> > you're setting them all the time for all of the builds that you're
> > doing, it would make more sense to create a distro layer that sets
> > them - then it's simply a matter of ensuring that layer is added to
> > your bblayers.conf and you set DISTRO as appropriate.
> > 
> > AFAIK the command line options in question were added to allow
> > frontends to inject configuration into bitbake rather than something
> > the user would normally use directly.
> 
>   ok, that makes sense.  but would it also make sense for bitbake to
> perhaps support another option that *does* allow personal content to,
> say, be effectively appended to one's local.conf.  for instance, every
> single local.conf i create immediately gets this added to the end:
> 
> SOURCE_MIRROR_URL ?= "file:///home/rpjday/dl/"
> INHERIT += "own-mirrors"
> BB_GENERATE_MIRROR_TARBALLS = "1"
> # BB_NO_NETWORK = "1"

OK, looking at the settings you've listed, I think these are the kinds of 
things that site.conf was invented for - stuff that is specific not to the 
builds you are doing but to the host machine / site. You can simply put these 
settings in a file called site.conf next to local.conf and they'll be read from 
there; for new build directories you can just copy it in or symlink it from 
some common location.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] the current yocto FAQ is pretty much valueless

On Tue, 26 Jun 2012, Paul Eggleton wrote:

> On Tuesday 26 June 2012 12:51:15 Robert P. J. Day wrote:
> > On Tue, 26 Jun 2012, Paul Eggleton wrote:
> > > On Tuesday 26 June 2012 12:26:28 Robert P. J. Day wrote:
> > > >   i thought that was the technique for centralizing personal config
> > > >
> > > > preferences that you *didn't* want to manually copy into every
> > > > local.conf file you created.  if you add that personal content into
> > > > each local.conf, then of course you don't need those options.
> > >
> > > I guess it depends on what you mean by "personal content". Certain
> > > settings are really part of distro policy and if you're finding that
> > > you're setting them all the time for all of the builds that you're
> > > doing, it would make more sense to create a distro layer that sets
> > > them - then it's simply a matter of ensuring that layer is added to
> > > your bblayers.conf and you set DISTRO as appropriate.
> > >
> > > AFAIK the command line options in question were added to allow
> > > frontends to inject configuration into bitbake rather than something
> > > the user would normally use directly.
> >
> >   ok, that makes sense.  but would it also make sense for bitbake to
> > perhaps support another option that *does* allow personal content to,
> > say, be effectively appended to one's local.conf.  for instance, every
> > single local.conf i create immediately gets this added to the end:
> >
> > SOURCE_MIRROR_URL ?= "file:///home/rpjday/dl/"
> > INHERIT += "own-mirrors"
> > BB_GENERATE_MIRROR_TARBALLS = "1"
> > # BB_NO_NETWORK = "1"
>
> OK, looking at the settings you've listed, I think these are the
> kinds of things that site.conf was invented for - stuff that is
> specific not to the builds you are doing but to the host machine /
> site. You can simply put these settings in a file called site.conf
> next to local.conf and they'll be read from there; for new build
> directories you can just copy it in or symlink it from some common
> location.

  that still requires just a touch of user intervention.  no totally
automatic way to do that, then?  it's at least an improvement over
manual copying, thanks.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [yocto] the current yocto FAQ is pretty much valueless

So this situation might lend itself to a nice FAQ question Something like 
"How do I isolate site and machine specific information during a build?"  And 
the solution can tell them how to use a site.conf file.

Scott

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Paul Eggleton
Sent: Tuesday, June 26, 2012 10:02 AM
To: Robert P. J. Day
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] the current yocto FAQ is pretty much valueless

On Tuesday 26 June 2012 12:51:15 Robert P. J. Day wrote:
> On Tue, 26 Jun 2012, Paul Eggleton wrote:
> > On Tuesday 26 June 2012 12:26:28 Robert P. J. Day wrote:
> > >   i thought that was the technique for centralizing personal config
> > > 
> > > preferences that you *didn't* want to manually copy into every
> > > local.conf file you created.  if you add that personal content into
> > > each local.conf, then of course you don't need those options.
> > 
> > I guess it depends on what you mean by "personal content". Certain
> > settings are really part of distro policy and if you're finding that
> > you're setting them all the time for all of the builds that you're
> > doing, it would make more sense to create a distro layer that sets
> > them - then it's simply a matter of ensuring that layer is added to
> > your bblayers.conf and you set DISTRO as appropriate.
> > 
> > AFAIK the command line options in question were added to allow
> > frontends to inject configuration into bitbake rather than something
> > the user would normally use directly.
> 
>   ok, that makes sense.  but would it also make sense for bitbake to
> perhaps support another option that *does* allow personal content to,
> say, be effectively appended to one's local.conf.  for instance, every
> single local.conf i create immediately gets this added to the end:
> 
> SOURCE_MIRROR_URL ?= "file:///home/rpjday/dl/"
> INHERIT += "own-mirrors"
> BB_GENERATE_MIRROR_TARBALLS = "1"
> # BB_NO_NETWORK = "1"

OK, looking at the settings you've listed, I think these are the kinds of 
things that site.conf was invented for - stuff that is specific not to the 
builds you are doing but to the host machine / site. You can simply put these 
settings in a file called site.conf next to local.conf and they'll be read from 
there; for new build directories you can just copy it in or symlink it from 
some common location.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
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] the current yocto FAQ is pretty much valueless

On Tuesday 26 June 2012 13:05:21 Robert P. J. Day wrote:
> On Tue, 26 Jun 2012, Paul Eggleton wrote:
> > On Tuesday 26 June 2012 12:51:15 Robert P. J. Day wrote:
> > >   ok, that makes sense.  but would it also make sense for bitbake to
> > > perhaps support another option that *does* allow personal content to,
> > > say, be effectively appended to one's local.conf.  for instance, every
> > > single local.conf i create immediately gets this added to the end:
> > > 
> > > SOURCE_MIRROR_URL ?= "file:///home/rpjday/dl/"
> > > INHERIT += "own-mirrors"
> > > BB_GENERATE_MIRROR_TARBALLS = "1"
> > > # BB_NO_NETWORK = "1"
> > 
> > OK, looking at the settings you've listed, I think these are the
> > kinds of things that site.conf was invented for - stuff that is
> > specific not to the builds you are doing but to the host machine /
> > site. You can simply put these settings in a file called site.conf
> > next to local.conf and they'll be read from there; for new build
> > directories you can just copy it in or symlink it from some common
> > location.
> 
>   that still requires just a touch of user intervention.  no totally
> automatic way to do that, then?  it's at least an improvement over
> manual copying, thanks.

I have thought about this - it would be great if oe-init-build-env could 
copy/symlink your customised version from somewhere automatically every time; 
however the question would be how would it know where to copy it from? I'm not 
sure an added command-line option would be much better than just getting 
people to copy/symlink it in manually.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] the current yocto FAQ is pretty much valueless

On Tue, 26 Jun 2012, Rifenbark, Scott M wrote:

> So this situation might lend itself to a nice FAQ question
> Something like "How do I isolate site and machine specific
> information during a build?"  And the solution can tell them how to
> use a site.conf file.

  yes, but it would also need information on ordering of consultation.
from bitbake.conf:

require conf/abi_version.conf
include conf/site.conf
include conf/auto.conf
include conf/local.conf
include conf/build/${BUILD_SYS}.conf
include conf/target/${TARGET_SYS}.conf
include conf/machine/${MACHINE}.conf
include conf/machine-sdk/${SDKMACHINE}.conf
include conf/distro/${DISTRO}.conf
include conf/distro/defaultsetup.conf
include conf/documentation.conf
require conf/sanity.conf

  is it safe to assume that the ordering there is important, and that
files are consulted top down?  if that's the case, it's useful to
explain that the site.conf file would be consulted before one's
local.conf file (if that's in fact the case).

rday

-- 

Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [yocto] the current yocto FAQ is pretty much valueless

On Tue, 26 Jun 2012, Paul Eggleton wrote:

> On Tuesday 26 June 2012 13:05:21 Robert P. J. Day wrote:
> > On Tue, 26 Jun 2012, Paul Eggleton wrote:
> > > On Tuesday 26 June 2012 12:51:15 Robert P. J. Day wrote:
> > > >   ok, that makes sense.  but would it also make sense for bitbake to
> > > > perhaps support another option that *does* allow personal content to,
> > > > say, be effectively appended to one's local.conf.  for instance, every
> > > > single local.conf i create immediately gets this added to the end:
> > > >
> > > > SOURCE_MIRROR_URL ?= "file:///home/rpjday/dl/"
> > > > INHERIT += "own-mirrors"
> > > > BB_GENERATE_MIRROR_TARBALLS = "1"
> > > > # BB_NO_NETWORK = "1"
> > >
> > > OK, looking at the settings you've listed, I think these are the
> > > kinds of things that site.conf was invented for - stuff that is
> > > specific not to the builds you are doing but to the host machine /
> > > site. You can simply put these settings in a file called site.conf
> > > next to local.conf and they'll be read from there; for new build
> > > directories you can just copy it in or symlink it from some common
> > > location.
> >
> >   that still requires just a touch of user intervention.  no totally
> > automatic way to do that, then?  it's at least an improvement over
> > manual copying, thanks.
>
> I have thought about this - it would be great if oe-init-build-env could
> copy/symlink your customised version from somewhere automatically every time;
> however the question would be how would it know where to copy it from? I'm not
> sure an added command-line option would be much better than just getting
> people to copy/symlink it in manually.

  that's fine, i'll at least note this shortcut.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [yocto] the current yocto FAQ is pretty much valueless

2012-06-26 Thread Tomas Frydrych

On 26/06/12 17:53, Robert P. J. Day wrote:
>   and if you want major industry players to take yocto seriously, the
> last thing you want to do is answer their heartfelt pleas for
> assistance with, "i'm sorry, that's technically not a yocto question,
> you should try another mailing list."

That's never been case on this list as far as I recall, folk here are
pretty responsive to questions being asked.

At the same time, OE/Poky/Yocto is a fairly complex framework and nobody
should expect that the necessary expertize to build a commercial grade
products with it can be acquired by simply reading a FAQ, no matter how
well written, or by just endlessly asking questions on a mailing list.
As a commercial player you are either prepared to make the in house
investment that is necessary to acquire that expertize (reading the
documentation and studying the source code, etc.), or you you can buy
the expertize on commercial basis from someone who has it.

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

Re: [yocto] Yocto Development Manual Appendix B question


On 12-06-26 12:30 PM, Rifenbark, Scott M wrote:

I am going to run through the B.1 example verbatim from the "current" version 
of the manual and see what happens.


Fixing the license check was just a matter of me locking the SRCREV
for the tools to a value that works for denzil. I just pushed a denzil
branch to poky-extras that built and booted the yocto kernel for
me.

Cheers,

Bruce



Scott

-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, June 26, 2012 9:28 AM
To: Rifenbark, Scott M
Cc: jfabernathy; yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

On 12-06-26 12:26 PM, Rifenbark, Scott M wrote:

This is a good point.  In looking at the example it does not say what branch 
you should be dealing with for poky-extras.


And I'm configuring a test right now and will create a denzil
branch, once I see it works.

Cheers,

Bruce



-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, June 26, 2012 9:24 AM
To: jfabernathy
Cc: Rifenbark, Scott M; yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

On 12-06-26 12:11 PM, jfabernathy wrote:

On 06/26/2012 12:04 PM, Bruce Ashfield wrote:

On 12-06-26 12:00 PM, jfabernathy wrote:

On 06/26/2012 10:56 AM, Rifenbark, Scott M wrote:

Bruce,

Should the example note this? Would it be best to specifically say to
uncomment that SRC_URI line?

Scott

I think some text needs to be added. I uncommented the SRC_URI line and
I still fail building the image. The failure is related to kernel tools:

ERROR: kern-tools-native: md5 data is not matching for
file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d843f43d2e22b0d91a6fee


ERROR: kern-tools-native: The new md5 checksum is
d8d1d729a70cd5f52972f8884b80743d
ERROR: kern-tools-native: Check if the license information has
changed in
ERROR: Licensing Error: LIC_FILES_CHKSUM does not match, please fix
ERROR: Function failed: do_qa_configure


This one is actually fixed on master, but poky-extras .. is just that
'extra', so this may still be alive in that repo.

This wouldn't need to be documented, since it's a bug/issue, and not
something that would persist.

What release are you pairing poky extras with ? I can always create a
branch to make sure they are consistent.



I was using Denzil because the snapshot noted in the example does not
exist. So there is another doc issue.


Aha. In this case, we could note that the poky-extras repo branch should
match the main repository branch .. and I could ensure that meta-kernel-dev
works in that configuration.

That's likely the right solution, rather than forcing you to switch to
master (unless you want to :)

Cheers,

Bruce



I can always test on Master, but the docs need to be update to reflect
something that will work to completion without errors, IMHO.

Jim A


Cheers,

Bruce




Jim A


-Original Message-
From: yocto-boun...@yoctoproject.org
[mailto:yocto-boun...@yoctoproject.org] On Behalf Of Bruce Ashfield
Sent: Tuesday, June 26, 2012 7:54 AM
To: jfabernathy
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

On 12-06-26 10:52 AM, jfabernathy wrote:

In the example in The Developement Manual v1.2 in Appendix B Section
B.1.7, it states that you need to put in the statement:

KSRC_linux_yocto_3_2 ?="/home/scottrif/linux-yocto-3.2.git"

into the appropriate .bbappend file way now in the poky-extra
directory
structure. If I look at that file, |linux-yocto_3.2.bbappend| , I
seen a
SRC_URI line, immediately after our inserted KSRC statement, that is
commented out:

# SRC_URI =
"git://${KSRC_linux_yocto_3_2};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"



Should that line be uncommented or is the SRC_URI already defaulted
somewhere to use the newly defined KSRC_linux_yocto_3_2 variable?

It should be uncommented. I commented them by default, since the extras
repository is a bit of a collection ground. If they are uncommented,
and
combined with the AUTOREV also set in the file, you are forced to fix
all files, versus just the one you want.

Cheers,

Bruce


Jim A





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

___
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] Yocto Development Manual Appendix B question

I am on task 1507 of 1606 of a minimal build (from the example).  No issues so 
far.

-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] 
Sent: Tuesday, June 26, 2012 10:42 AM
To: Rifenbark, Scott M
Cc: jfabernathy; yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

On 12-06-26 12:30 PM, Rifenbark, Scott M wrote:
> I am going to run through the B.1 example verbatim from the "current" version 
> of the manual and see what happens.

Fixing the license check was just a matter of me locking the SRCREV
for the tools to a value that works for denzil. I just pushed a denzil
branch to poky-extras that built and booted the yocto kernel for
me.

Cheers,

Bruce

>
> Scott
>
> -Original Message-
> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
> Sent: Tuesday, June 26, 2012 9:28 AM
> To: Rifenbark, Scott M
> Cc: jfabernathy; yocto@yoctoproject.org
> Subject: Re: [yocto] Yocto Development Manual Appendix B question
>
> On 12-06-26 12:26 PM, Rifenbark, Scott M wrote:
>> This is a good point.  In looking at the example it does not say what branch 
>> you should be dealing with for poky-extras.
>
> And I'm configuring a test right now and will create a denzil
> branch, once I see it works.
>
> Cheers,
>
> Bruce
>
>>
>> -Original Message-
>> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
>> Sent: Tuesday, June 26, 2012 9:24 AM
>> To: jfabernathy
>> Cc: Rifenbark, Scott M; yocto@yoctoproject.org
>> Subject: Re: [yocto] Yocto Development Manual Appendix B question
>>
>> On 12-06-26 12:11 PM, jfabernathy wrote:
>>> On 06/26/2012 12:04 PM, Bruce Ashfield wrote:
 On 12-06-26 12:00 PM, jfabernathy wrote:
> On 06/26/2012 10:56 AM, Rifenbark, Scott M wrote:
>> Bruce,
>>
>> Should the example note this? Would it be best to specifically say to
>> uncomment that SRC_URI line?
>>
>> Scott
> I think some text needs to be added. I uncommented the SRC_URI line and
> I still fail building the image. The failure is related to kernel tools:
>
> ERROR: kern-tools-native: md5 data is not matching for
> file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d843f43d2e22b0d91a6fee
>
>
> ERROR: kern-tools-native: The new md5 checksum is
> d8d1d729a70cd5f52972f8884b80743d
> ERROR: kern-tools-native: Check if the license information has
> changed in
> ERROR: Licensing Error: LIC_FILES_CHKSUM does not match, please fix
> ERROR: Function failed: do_qa_configure

 This one is actually fixed on master, but poky-extras .. is just that
 'extra', so this may still be alive in that repo.

 This wouldn't need to be documented, since it's a bug/issue, and not
 something that would persist.

 What release are you pairing poky extras with ? I can always create a
 branch to make sure they are consistent.

>>>
>>> I was using Denzil because the snapshot noted in the example does not
>>> exist. So there is another doc issue.
>>
>> Aha. In this case, we could note that the poky-extras repo branch should
>> match the main repository branch .. and I could ensure that meta-kernel-dev
>> works in that configuration.
>>
>> That's likely the right solution, rather than forcing you to switch to
>> master (unless you want to :)
>>
>> Cheers,
>>
>> Bruce
>>
>>>
>>> I can always test on Master, but the docs need to be update to reflect
>>> something that will work to completion without errors, IMHO.
>>>
>>> Jim A
>>>
 Cheers,

 Bruce

>
>
> Jim A
>
>> -Original Message-
>> From: yocto-boun...@yoctoproject.org
>> [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Bruce Ashfield
>> Sent: Tuesday, June 26, 2012 7:54 AM
>> To: jfabernathy
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] Yocto Development Manual Appendix B question
>>
>> On 12-06-26 10:52 AM, jfabernathy wrote:
>>> In the example in The Developement Manual v1.2 in Appendix B Section
>>> B.1.7, it states that you need to put in the statement:
>>>
>>> KSRC_linux_yocto_3_2 ?="/home/scottrif/linux-yocto-3.2.git"
>>>
>>> into the appropriate .bbappend file way now in the poky-extra
>>> directory
>>> structure. If I look at that file, |linux-yocto_3.2.bbappend| , I
>>> seen a
>>> SRC_URI line, immediately after our inserted KSRC statement, that is
>>> commented out:
>>>
>>> # SRC_URI =
>>> "git://${KSRC_linux_yocto_3_2};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
>>>
>>>
>>>
>>> Should that line be uncommented or is the SRC_URI already defaulted
>>> somewhere to use the newly defined KSRC_linux_yocto_3_2 variable?
>> It should be uncommented. I commented them by default, since the extras
>> repository is a bit of a collection ground. If they are uncommented,
>> and
>> combined with th

Re: [yocto] the current yocto FAQ is pretty much valueless

2012-06-26 Thread Brian Duffy

No, an FAQ should not get you the expertise to create a commercial grade
product. Reading the documentation should though. You don't want users to
have to study source code.

On Tue, Jun 26, 2012 at 1:18 PM, Tomas Frydrych  wrote:

> On 26/06/12 17:53, Robert P. J. Day wrote:
> >   and if you want major industry players to take yocto seriously, the
> > last thing you want to do is answer their heartfelt pleas for
> > assistance with, "i'm sorry, that's technically not a yocto question,
> > you should try another mailing list."
>
> That's never been case on this list as far as I recall, folk here are
> pretty responsive to questions being asked.
>
> At the same time, OE/Poky/Yocto is a fairly complex framework and nobody
> should expect that the necessary expertize to build a commercial grade
> products with it can be acquired by simply reading a FAQ, no matter how
> well written, or by just endlessly asking questions on a mailing list.
> As a commercial player you are either prepared to make the in house
> investment that is necessary to acquire that expertize (reading the
> documentation and studying the source code, etc.), or you you can buy
> the expertize on commercial basis from someone who has it.
>
> Tomas
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



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

Re: [yocto] Yocto Development Manual Appendix B question

When I attempted to rebuild minimal I hit the same error you did Jim regarding 
kern-tools-native.  This would be expected as Bruce pointed out that problem is 
alive in denzil.  I am going to set the poky-extras branch to 'denzil' and 
retry that part of the example.

Scott

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Rifenbark, Scott M
Sent: Tuesday, June 26, 2012 10:44 AM
To: Bruce Ashfield
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

I am on task 1507 of 1606 of a minimal build (from the example).  No issues so 
far.

-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] 
Sent: Tuesday, June 26, 2012 10:42 AM
To: Rifenbark, Scott M
Cc: jfabernathy; yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

On 12-06-26 12:30 PM, Rifenbark, Scott M wrote:
> I am going to run through the B.1 example verbatim from the "current" version 
> of the manual and see what happens.

Fixing the license check was just a matter of me locking the SRCREV
for the tools to a value that works for denzil. I just pushed a denzil
branch to poky-extras that built and booted the yocto kernel for
me.

Cheers,

Bruce

>
> Scott
>
> -Original Message-
> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
> Sent: Tuesday, June 26, 2012 9:28 AM
> To: Rifenbark, Scott M
> Cc: jfabernathy; yocto@yoctoproject.org
> Subject: Re: [yocto] Yocto Development Manual Appendix B question
>
> On 12-06-26 12:26 PM, Rifenbark, Scott M wrote:
>> This is a good point.  In looking at the example it does not say what branch 
>> you should be dealing with for poky-extras.
>
> And I'm configuring a test right now and will create a denzil
> branch, once I see it works.
>
> Cheers,
>
> Bruce
>
>>
>> -Original Message-
>> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
>> Sent: Tuesday, June 26, 2012 9:24 AM
>> To: jfabernathy
>> Cc: Rifenbark, Scott M; yocto@yoctoproject.org
>> Subject: Re: [yocto] Yocto Development Manual Appendix B question
>>
>> On 12-06-26 12:11 PM, jfabernathy wrote:
>>> On 06/26/2012 12:04 PM, Bruce Ashfield wrote:
 On 12-06-26 12:00 PM, jfabernathy wrote:
> On 06/26/2012 10:56 AM, Rifenbark, Scott M wrote:
>> Bruce,
>>
>> Should the example note this? Would it be best to specifically say to
>> uncomment that SRC_URI line?
>>
>> Scott
> I think some text needs to be added. I uncommented the SRC_URI line and
> I still fail building the image. The failure is related to kernel tools:
>
> ERROR: kern-tools-native: md5 data is not matching for
> file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d843f43d2e22b0d91a6fee
>
>
> ERROR: kern-tools-native: The new md5 checksum is
> d8d1d729a70cd5f52972f8884b80743d
> ERROR: kern-tools-native: Check if the license information has
> changed in
> ERROR: Licensing Error: LIC_FILES_CHKSUM does not match, please fix
> ERROR: Function failed: do_qa_configure

 This one is actually fixed on master, but poky-extras .. is just that
 'extra', so this may still be alive in that repo.

 This wouldn't need to be documented, since it's a bug/issue, and not
 something that would persist.

 What release are you pairing poky extras with ? I can always create a
 branch to make sure they are consistent.

>>>
>>> I was using Denzil because the snapshot noted in the example does not
>>> exist. So there is another doc issue.
>>
>> Aha. In this case, we could note that the poky-extras repo branch should
>> match the main repository branch .. and I could ensure that meta-kernel-dev
>> works in that configuration.
>>
>> That's likely the right solution, rather than forcing you to switch to
>> master (unless you want to :)
>>
>> Cheers,
>>
>> Bruce
>>
>>>
>>> I can always test on Master, but the docs need to be update to reflect
>>> something that will work to completion without errors, IMHO.
>>>
>>> Jim A
>>>
 Cheers,

 Bruce

>
>
> Jim A
>
>> -Original Message-
>> From: yocto-boun...@yoctoproject.org
>> [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Bruce Ashfield
>> Sent: Tuesday, June 26, 2012 7:54 AM
>> To: jfabernathy
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] Yocto Development Manual Appendix B question
>>
>> On 12-06-26 10:52 AM, jfabernathy wrote:
>>> In the example in The Developement Manual v1.2 in Appendix B Section
>>> B.1.7, it states that you need to put in the statement:
>>>
>>> KSRC_linux_yocto_3_2 ?="/home/scottrif/linux-yocto-3.2.git"
>>>
>>> into the appropriate .bbappend file way now in the poky-extra
>>> directory
>>> structure. If I look at that file, |linux-yocto_3.2.bbappend| , I
>>> seen a
>>> SRC_URI line, immediately

Re: [yocto] the current yocto FAQ is pretty much valueless

2012-06-26 Thread Tim Bird

On 06/26/2012 10:18 AM, Tomas Frydrych wrote:
> On 26/06/12 17:53, Robert P. J. Day wrote:
>>   and if you want major industry players to take yocto seriously, the
>> last thing you want to do is answer their heartfelt pleas for
>> assistance with, "i'm sorry, that's technically not a yocto question,
>> you should try another mailing list."
> 
> That's never been case on this list as far as I recall, folk here are
> pretty responsive to questions being asked.
> 
> At the same time, OE/Poky/Yocto is a fairly complex framework and nobody
> should expect that the necessary expertize to build a commercial grade
> products with it can be acquired by simply reading a FAQ, no matter how
> well written, or by just endlessly asking questions on a mailing list.
> As a commercial player you are either prepared to make the in house
> investment that is necessary to acquire that expertize (reading the
> documentation and studying the source code, etc.), or you you can buy
> the expertize on commercial basis from someone who has it.

Well, granted that OE/Poky/Yocto is fairly complex.  I've followed
OE for years (though never successfully built anything with it).
I had my first successful build of (Poky?, Yocto?) just recently,
with a build image I got from Dave Stewart at LinuxCon Japan.
(Thanks very much Dave!).

However, complexity is no excuse for terrible FAQs.  And the FAQ
on the wiki is pretty bad.  For example, after reading various FAQs
I still have no idea what kind of thing "Poky" is.  I know
that bitbake is a build tool.  I know that OE is a package
meta-information project.  Yocto Project is an umbrella project
for a lot of tools and technologies (Poky among them).  But is
Poky a distro (sample/reference or otherwise?) or something else?

When I ran my recently-built image, my target /etc/issue had this content:
"Yocto (Built by Poky 7.0) 1.2"

Is Poky a build system?  A distro? a managed set of package sources
and build information?

I don't even know what to make of this.  And this is from a developer
pushing Yocto inside my company (where we are making the "in-house
investment" that is claimed to be needed to do something with this.)

Now, here's my disclaimer: I read the manuals in the past
and found them hard to follow, and thus finding my desire to
read them again somewhat diminished, I haven't done so lately.
Also, I don't mean to pick on "Poky" - that's just the thing du-jour
that I'm not clear about within the Yocto Project.
Maybe the definition of Poky is crystal clear somewhere in the docs.
If so, sorry for the rant.

But yeah, a FAQ cleanup and build-out would be good.  I think one
problem is that various people who are qualified to make FAQ entries
are so close to the project that certain features and terminology
are second-nature to them, and go unspoken or unclarified in the
entries. I'm not in this category, so if I find some time I'll
try to make a few FAQ entries that address the points of
confusion I've seen.
 -- Tim

=
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=

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

[yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, June 26, 2012 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).

2012-06-26 Thread Liu, Song

Attendees:
LaurentiuP, Jefro, Richard, Bruce, Michael, Ross, Mark, Sean, Jeff, Tom, 
Darren, Gilbert, Denys, Jessica, ScottR, Saul, Paul, Jim, Ciby, Alex, Song
 
Gilbert is from mentor Graphics, working with Sean.
 
Agenda:
 
* Opens collection - 5 min (Song)
* 1.3 M1 release readiness - 10 min (community)
  - The community agreed on releasing M1 RC1. For details, please see: 
https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status#Milestone_1 
* 1.2.1 update - 5 min (ScottG)
  - Ross did a fix for 1.2.1, Saul is going to pull and merge. We will have a 
build this week.
* 1.1.2 update - 5 min (Josh/Beth)
  - Beth did a rebuild, the build is ready for QA to test.
  - QA is busy with 1.2 meta-intel BSP testing now. Will complete in a couple 
more days.
* Yocto 1.3 status  - 10 min (Song/team)
  - Reviewed all P1 items left on 'scheduled' stage. 
  - Actions:
1) Darren/Bruce will get back to Song on 1649 and 1919. They may have to be 
rescheduled. 
2) 2390/2401: development completed, waiting for Juno release.
3) Song to follow up on all other P1's still in 'scheduled' stage for M2.
* SWAT team rotation: Nitin -> Beth
* Opens - 5 min
  - None
 
* Team sharing - 20 min
  Mark: working on ability to generate SDK/tool chain based on an image. Will 
have preliminary patches out to oe-core mailing list sometime this week.
  LaurentiuP: Working on 1.3 items. Has discussion on Bjorn last week, will 
follow up with him offline. 
  Michael: last week worked on testopia, release training with Beth, package 
reporting system, more autobuilder setup. Had some downtime on 
yoctoproject.org, worked to restore, will monitor it more closely. This coming 
week will be on bugzilla stats. 
  Jim: we have design update for web hob. Screen cast, PDF, etc. more feedback 
is appreciated. The URL is in the mailing list (last Friday).
  Darren: working on building kernel modules on target. Running into some issue 
(Post install scripts?), any idea or thoughts, let me know. The issue is bug 
1614 in Bugzilla.

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

[yocto] How to clean

2012-06-26 Thread Dallas Clement

I'd like to clean all of my build output so that I can rebuild with a
different toolchain.  What is the best way to clean without having to
redownload all of my source packages again?

I can see that something like this

$ bitbake -c cleanall linux-yocto

can clean the kernel or an individual package.  I want to clean everything.

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

Re: [yocto] Yocto Development Manual Appendix B question


On 06/26/2012 02:07 PM, Rifenbark, Scott M wrote:

When I attempted to rebuild minimal I hit the same error you did Jim regarding 
kern-tools-native.  This would be expected as Bruce pointed out that problem is 
alive in denzil.  I am going to set the poky-extras branch to 'denzil' and 
retry that part of the example.

Scott

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Rifenbark, Scott M
Sent: Tuesday, June 26, 2012 10:44 AM
To: Bruce Ashfield
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

I am on task 1507 of 1606 of a minimal build (from the example).  No issues so 
far.


I just finished testing with Denzil branch on poky and poky-extra. I 
made the Hello printk mods and used the new bbappend that Bruce setup in 
poky-extra for denzil.  I think he had already uncommented the SRC_URI 
and all I had to do was put in the statement from the Appendix B about 
KSRC. and mod the bblayer.conf to include poky-extra.


Everything compiled and worked as expected.

Jim A


-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, June 26, 2012 10:42 AM
To: Rifenbark, Scott M
Cc: jfabernathy; yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

On 12-06-26 12:30 PM, Rifenbark, Scott M wrote:

I am going to run through the B.1 example verbatim from the "current" version 
of the manual and see what happens.

Fixing the license check was just a matter of me locking the SRCREV
for the tools to a value that works for denzil. I just pushed a denzil
branch to poky-extras that built and booted the yocto kernel for
me.

Cheers,

Bruce


Scott

-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, June 26, 2012 9:28 AM
To: Rifenbark, Scott M
Cc: jfabernathy; yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

On 12-06-26 12:26 PM, Rifenbark, Scott M wrote:

This is a good point.  In looking at the example it does not say what branch 
you should be dealing with for poky-extras.

And I'm configuring a test right now and will create a denzil
branch, once I see it works.

Cheers,

Bruce


-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, June 26, 2012 9:24 AM
To: jfabernathy
Cc: Rifenbark, Scott M; yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

On 12-06-26 12:11 PM, jfabernathy wrote:

On 06/26/2012 12:04 PM, Bruce Ashfield wrote:

On 12-06-26 12:00 PM, jfabernathy wrote:

On 06/26/2012 10:56 AM, Rifenbark, Scott M wrote:

Bruce,

Should the example note this? Would it be best to specifically say to
uncomment that SRC_URI line?

Scott

I think some text needs to be added. I uncommented the SRC_URI line and
I still fail building the image. The failure is related to kernel tools:

ERROR: kern-tools-native: md5 data is not matching for
file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d843f43d2e22b0d91a6fee


ERROR: kern-tools-native: The new md5 checksum is
d8d1d729a70cd5f52972f8884b80743d
ERROR: kern-tools-native: Check if the license information has
changed in
ERROR: Licensing Error: LIC_FILES_CHKSUM does not match, please fix
ERROR: Function failed: do_qa_configure

This one is actually fixed on master, but poky-extras .. is just that
'extra', so this may still be alive in that repo.

This wouldn't need to be documented, since it's a bug/issue, and not
something that would persist.

What release are you pairing poky extras with ? I can always create a
branch to make sure they are consistent.


I was using Denzil because the snapshot noted in the example does not
exist. So there is another doc issue.

Aha. In this case, we could note that the poky-extras repo branch should
match the main repository branch .. and I could ensure that meta-kernel-dev
works in that configuration.

That's likely the right solution, rather than forcing you to switch to
master (unless you want to :)

Cheers,

Bruce


I can always test on Master, but the docs need to be update to reflect
something that will work to completion without errors, IMHO.

Jim A


Cheers,

Bruce



Jim A


-Original Message-
From: yocto-boun...@yoctoproject.org
[mailto:yocto-boun...@yoctoproject.org] On Behalf Of Bruce Ashfield
Sent: Tuesday, June 26, 2012 7:54 AM
To: jfabernathy
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

On 12-06-26 10:52 AM, jfabernathy wrote:

In the example in The Developement Manual v1.2 in Appendix B Section
B.1.7, it states that you need to put in the statement:

KSRC_linux_yocto_3_2 ?="/home/scottrif/linux-yocto-3.2.git"

into the appropriate .bbappend file way now in the poky-extra
directory
structure. If I look at that file, |linux-yocto_3.2.bbappend| , I
seen a
SRC_URI line, immediately after our inserted KSRC s

Re: [yocto] Yocto Development Manual Appendix B question


On 06/26/2012 02:07 PM, Rifenbark, Scott M wrote:

When I attempted to rebuild minimal I hit the same error you did Jim regarding 
kern-tools-native.  This would be expected as Bruce pointed out that problem is 
alive in denzil.  I am going to set the poky-extras branch to 'denzil' and 
retry that part of the example.

Scott

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Rifenbark, Scott M
Sent: Tuesday, June 26, 2012 10:44 AM
To: Bruce Ashfield
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

I am on task 1507 of 1606 of a minimal build (from the example).  No issues so 
far.


So now that Denzil has a branch in poky-extra, the only doc change is to 
add the checkout -b denzil statement for the poky-extra directory. 
Everything else is correct.


Jim A


-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, June 26, 2012 10:42 AM
To: Rifenbark, Scott M
Cc: jfabernathy; yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

On 12-06-26 12:30 PM, Rifenbark, Scott M wrote:

I am going to run through the B.1 example verbatim from the "current" version 
of the manual and see what happens.

Fixing the license check was just a matter of me locking the SRCREV
for the tools to a value that works for denzil. I just pushed a denzil
branch to poky-extras that built and booted the yocto kernel for
me.

Cheers,

Bruce


Scott

-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, June 26, 2012 9:28 AM
To: Rifenbark, Scott M
Cc: jfabernathy; yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

On 12-06-26 12:26 PM, Rifenbark, Scott M wrote:

This is a good point.  In looking at the example it does not say what branch 
you should be dealing with for poky-extras.

And I'm configuring a test right now and will create a denzil
branch, once I see it works.

Cheers,

Bruce


-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, June 26, 2012 9:24 AM
To: jfabernathy
Cc: Rifenbark, Scott M; yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

On 12-06-26 12:11 PM, jfabernathy wrote:

On 06/26/2012 12:04 PM, Bruce Ashfield wrote:

On 12-06-26 12:00 PM, jfabernathy wrote:

On 06/26/2012 10:56 AM, Rifenbark, Scott M wrote:

Bruce,

Should the example note this? Would it be best to specifically say to
uncomment that SRC_URI line?

Scott

I think some text needs to be added. I uncommented the SRC_URI line and
I still fail building the image. The failure is related to kernel tools:

ERROR: kern-tools-native: md5 data is not matching for
file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d843f43d2e22b0d91a6fee


ERROR: kern-tools-native: The new md5 checksum is
d8d1d729a70cd5f52972f8884b80743d
ERROR: kern-tools-native: Check if the license information has
changed in
ERROR: Licensing Error: LIC_FILES_CHKSUM does not match, please fix
ERROR: Function failed: do_qa_configure

This one is actually fixed on master, but poky-extras .. is just that
'extra', so this may still be alive in that repo.

This wouldn't need to be documented, since it's a bug/issue, and not
something that would persist.

What release are you pairing poky extras with ? I can always create a
branch to make sure they are consistent.


I was using Denzil because the snapshot noted in the example does not
exist. So there is another doc issue.

Aha. In this case, we could note that the poky-extras repo branch should
match the main repository branch .. and I could ensure that meta-kernel-dev
works in that configuration.

That's likely the right solution, rather than forcing you to switch to
master (unless you want to :)

Cheers,

Bruce


I can always test on Master, but the docs need to be update to reflect
something that will work to completion without errors, IMHO.

Jim A


Cheers,

Bruce



Jim A


-Original Message-
From: yocto-boun...@yoctoproject.org
[mailto:yocto-boun...@yoctoproject.org] On Behalf Of Bruce Ashfield
Sent: Tuesday, June 26, 2012 7:54 AM
To: jfabernathy
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

On 12-06-26 10:52 AM, jfabernathy wrote:

In the example in The Developement Manual v1.2 in Appendix B Section
B.1.7, it states that you need to put in the statement:

KSRC_linux_yocto_3_2 ?="/home/scottrif/linux-yocto-3.2.git"

into the appropriate .bbappend file way now in the poky-extra
directory
structure. If I look at that file, |linux-yocto_3.2.bbappend| , I
seen a
SRC_URI line, immediately after our inserted KSRC statement, that is
commented out:

# SRC_URI =
"git://${KSRC_linux_yocto_3_2};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"



Should that line be uncommented or is the SRC_URI already defaulted

Re: [yocto] How to clean

2012-06-26 Thread Khem Raj

On Tue, Jun 26, 2012 at 12:21 PM, Dallas Clement
 wrote:
>
>
> can clean the kernel or an individual package.  I want to clean everything.

by default DL_DIR lives outside TMPDIR so you can delete the TMPDIR
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to clean

2012-06-26 Thread Stewart, David C

>From: yocto-boun...@yoctoproject.org [mailto:yocto-
>boun...@yoctoproject.org] On Behalf Of Dallas Clement
>Sent: Tuesday, June 26, 2012 12:21 PM
>
>I'd like to clean all of my build output so that I can rebuild with a
>different toolchain.  What is the best way to clean without having to
>redownload all of my source packages again?
>
>I can see that something like this
>
>$ bitbake -c cleanall linux-yocto
>
>can clean the kernel or an individual package.  I want to clean everything.

I just delete the tmp directory and that seems to get the result I want - 
remove all the binaries but doesn't delete the sources.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to clean

On Tue, 26 Jun 2012, Dallas Clement wrote:

> I'd like to clean all of my build output so that I can rebuild with a
> different toolchain.  What is the best way to clean without having to
> redownload all of my source packages again?
>
> I can see that something like this
>
> $ bitbake -c cleanall linux-yocto
>
> can clean the kernel or an individual package.  I want to clean everything.

  hey, there's an FAQ entry for that! :-)  well, sort of ... if you
want to avoid all that source downloading:

http://www.crashcourse.ca/wiki/index.php/Yocto_FAQ#How_can_I_set_up_a_local_mirror_of_tarballs_to_save_download_time.3F

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [yocto] Yocto Development Manual Appendix B question

Jim, 

Yes - I am still running the very last part of my test.  If that is the change 
then I will make it to the 1.2 version of the manual and publish it to the 
website.  

Scott

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of jfabernathy
Sent: Tuesday, June 26, 2012 12:50 PM
To: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

On 06/26/2012 02:07 PM, Rifenbark, Scott M wrote:
> When I attempted to rebuild minimal I hit the same error you did Jim 
> regarding kern-tools-native.  This would be expected as Bruce pointed out 
> that problem is alive in denzil.  I am going to set the poky-extras branch to 
> 'denzil' and retry that part of the example.
>
> Scott
>
> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] 
> On Behalf Of Rifenbark, Scott M
> Sent: Tuesday, June 26, 2012 10:44 AM
> To: Bruce Ashfield
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Yocto Development Manual Appendix B question
>
> I am on task 1507 of 1606 of a minimal build (from the example).  No issues 
> so far.

So now that Denzil has a branch in poky-extra, the only doc change is to 
add the checkout -b denzil statement for the poky-extra directory. 
Everything else is correct.

Jim A

> -Original Message-
> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
> Sent: Tuesday, June 26, 2012 10:42 AM
> To: Rifenbark, Scott M
> Cc: jfabernathy; yocto@yoctoproject.org
> Subject: Re: [yocto] Yocto Development Manual Appendix B question
>
> On 12-06-26 12:30 PM, Rifenbark, Scott M wrote:
>> I am going to run through the B.1 example verbatim from the "current" 
>> version of the manual and see what happens.
> Fixing the license check was just a matter of me locking the SRCREV
> for the tools to a value that works for denzil. I just pushed a denzil
> branch to poky-extras that built and booted the yocto kernel for
> me.
>
> Cheers,
>
> Bruce
>
>> Scott
>>
>> -Original Message-
>> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
>> Sent: Tuesday, June 26, 2012 9:28 AM
>> To: Rifenbark, Scott M
>> Cc: jfabernathy; yocto@yoctoproject.org
>> Subject: Re: [yocto] Yocto Development Manual Appendix B question
>>
>> On 12-06-26 12:26 PM, Rifenbark, Scott M wrote:
>>> This is a good point.  In looking at the example it does not say what 
>>> branch you should be dealing with for poky-extras.
>> And I'm configuring a test right now and will create a denzil
>> branch, once I see it works.
>>
>> Cheers,
>>
>> Bruce
>>
>>> -Original Message-
>>> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
>>> Sent: Tuesday, June 26, 2012 9:24 AM
>>> To: jfabernathy
>>> Cc: Rifenbark, Scott M; yocto@yoctoproject.org
>>> Subject: Re: [yocto] Yocto Development Manual Appendix B question
>>>
>>> On 12-06-26 12:11 PM, jfabernathy wrote:
 On 06/26/2012 12:04 PM, Bruce Ashfield wrote:
> On 12-06-26 12:00 PM, jfabernathy wrote:
>> On 06/26/2012 10:56 AM, Rifenbark, Scott M wrote:
>>> Bruce,
>>>
>>> Should the example note this? Would it be best to specifically say to
>>> uncomment that SRC_URI line?
>>>
>>> Scott
>> I think some text needs to be added. I uncommented the SRC_URI line and
>> I still fail building the image. The failure is related to kernel tools:
>>
>> ERROR: kern-tools-native: md5 data is not matching for
>> file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d843f43d2e22b0d91a6fee
>>
>>
>> ERROR: kern-tools-native: The new md5 checksum is
>> d8d1d729a70cd5f52972f8884b80743d
>> ERROR: kern-tools-native: Check if the license information has
>> changed in
>> ERROR: Licensing Error: LIC_FILES_CHKSUM does not match, please fix
>> ERROR: Function failed: do_qa_configure
> This one is actually fixed on master, but poky-extras .. is just that
> 'extra', so this may still be alive in that repo.
>
> This wouldn't need to be documented, since it's a bug/issue, and not
> something that would persist.
>
> What release are you pairing poky extras with ? I can always create a
> branch to make sure they are consistent.
>
 I was using Denzil because the snapshot noted in the example does not
 exist. So there is another doc issue.
>>> Aha. In this case, we could note that the poky-extras repo branch should
>>> match the main repository branch .. and I could ensure that meta-kernel-dev
>>> works in that configuration.
>>>
>>> That's likely the right solution, rather than forcing you to switch to
>>> master (unless you want to :)
>>>
>>> Cheers,
>>>
>>> Bruce
>>>
 I can always test on Master, but the docs need to be update to reflect
 something that will work to completion without errors, IMHO.

 Jim A

> Cheers,
>
> Bruce
>
>>
>> Jim A
>>
>>> -Original Message--

Re: [yocto] How to clean

On Tue, 26 Jun 2012, Stewart, David C wrote:

> >From: yocto-boun...@yoctoproject.org [mailto:yocto-
> >boun...@yoctoproject.org] On Behalf Of Dallas Clement
> >Sent: Tuesday, June 26, 2012 12:21 PM
> >
> >I'd like to clean all of my build output so that I can rebuild with a
> >different toolchain.  What is the best way to clean without having to
> >redownload all of my source packages again?
> >
> >I can see that something like this
> >
> >$ bitbake -c cleanall linux-yocto
> >
> >can clean the kernel or an individual package.  I want to clean everything.
>
> I just delete the tmp directory and that seems to get the result I
> want - remove all the binaries but doesn't delete the sources.

  ok, better answer than mine, and added to the FAQ.

http://www.crashcourse.ca/wiki/index.php/Yocto_FAQ#How_can_I_remove_all_of_the_build_output_so_I_can_start_over.3F

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

[yocto] meta-raspberrypi - Latest kernels won't run (summary)

I've updated the SRCREVs:

bootfiles : 542ee2c3a5aea50377b97ec0308eb884900512ca
kernel: f679f0534867d64a3672108d73bed5d349728f73

This build ok, but the kernel doesn't boot (screen shows the 'four-colours' 
kernel boot error). The bootfiles seem to be good as they will work with older 
kernels and the corresponding 'official' kernel image.

It seems as if:

1) Nothing works if it's built with master / GCC 4.7.0 (reported by Paul 
Eggleton);
2) Earlier images work with Denzil / GCC 4.6.4;
3) Building with Edison / GCC 4.5.1 didn't seem to help.

Notes:

1) The built kernel is about 50% the size of the official one;
2) I've seen references to a change in the (default) enable state of the L2 
cache (it's now on by default).
3) Is the RPi toolchain patched? It's reported as GCC 4.5.1 (Broadcom 2708) in 
/proc/version. I've asked where the source is, but have not heard anything yet.
4) Khem Raj has noted that there are changes in .config that may be an issue.
5) Nothing comes out of the serial console when an image fails.

Has anyone got any ideas how to get the latest kernel to work?

Chris Tapp

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



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

Re: [yocto] Yocto Development Manual Appendix B question


On 06/26/2012 04:21 PM, Rifenbark, Scott M wrote:

Jim,

Yes - I am still running the very last part of my test.  If that is the change 
then I will make it to the 1.2 version of the manual and publish it to the 
website.

Scott


While I had this working I thought I'd complete the Appendix B example 
for the CONFIG_SMP change.  I'm finding problems with the compile step 
after menuconfig is run to turn off SMP.  I get a mismatch that I don't 
understand:


Value requested for CONFIG_SMP not in final ".config"
Requested value: "CONFIG_SMP=y"
Actual value set: "# CONFIG_SMP is not set"

There must be another setting of CONFIG_SMP that is conflicting with the 
.config file


Jim A


-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of jfabernathy
Sent: Tuesday, June 26, 2012 12:50 PM
To: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

On 06/26/2012 02:07 PM, Rifenbark, Scott M wrote:

When I attempted to rebuild minimal I hit the same error you did Jim regarding 
kern-tools-native.  This would be expected as Bruce pointed out that problem is 
alive in denzil.  I am going to set the poky-extras branch to 'denzil' and 
retry that part of the example.

Scott

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Rifenbark, Scott M
Sent: Tuesday, June 26, 2012 10:44 AM
To: Bruce Ashfield
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

I am on task 1507 of 1606 of a minimal build (from the example).  No issues so 
far.

So now that Denzil has a branch in poky-extra, the only doc change is to
add the checkout -b denzil statement for the poky-extra directory.
Everything else is correct.

Jim A


-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, June 26, 2012 10:42 AM
To: Rifenbark, Scott M
Cc: jfabernathy; yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

On 12-06-26 12:30 PM, Rifenbark, Scott M wrote:

I am going to run through the B.1 example verbatim from the "current" version 
of the manual and see what happens.

Fixing the license check was just a matter of me locking the SRCREV
for the tools to a value that works for denzil. I just pushed a denzil
branch to poky-extras that built and booted the yocto kernel for
me.

Cheers,

Bruce


Scott

-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, June 26, 2012 9:28 AM
To: Rifenbark, Scott M
Cc: jfabernathy; yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

On 12-06-26 12:26 PM, Rifenbark, Scott M wrote:

This is a good point.  In looking at the example it does not say what branch 
you should be dealing with for poky-extras.

And I'm configuring a test right now and will create a denzil
branch, once I see it works.

Cheers,

Bruce


-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, June 26, 2012 9:24 AM
To: jfabernathy
Cc: Rifenbark, Scott M; yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

On 12-06-26 12:11 PM, jfabernathy wrote:

On 06/26/2012 12:04 PM, Bruce Ashfield wrote:

On 12-06-26 12:00 PM, jfabernathy wrote:

On 06/26/2012 10:56 AM, Rifenbark, Scott M wrote:

Bruce,

Should the example note this? Would it be best to specifically say to
uncomment that SRC_URI line?

Scott

I think some text needs to be added. I uncommented the SRC_URI line and
I still fail building the image. The failure is related to kernel tools:

ERROR: kern-tools-native: md5 data is not matching for
file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d843f43d2e22b0d91a6fee


ERROR: kern-tools-native: The new md5 checksum is
d8d1d729a70cd5f52972f8884b80743d
ERROR: kern-tools-native: Check if the license information has
changed in
ERROR: Licensing Error: LIC_FILES_CHKSUM does not match, please fix
ERROR: Function failed: do_qa_configure

This one is actually fixed on master, but poky-extras .. is just that
'extra', so this may still be alive in that repo.

This wouldn't need to be documented, since it's a bug/issue, and not
something that would persist.

What release are you pairing poky extras with ? I can always create a
branch to make sure they are consistent.


I was using Denzil because the snapshot noted in the example does not
exist. So there is another doc issue.

Aha. In this case, we could note that the poky-extras repo branch should
match the main repository branch .. and I could ensure that meta-kernel-dev
works in that configuration.

That's likely the right solution, rather than forcing you to switch to
master (unless you want to :)

Cheers,

Bruce


I can always test on Master, but the docs need to be update to reflect
something that will work to completion without errors, IMHO.

Jim A

Re: [yocto] Yocto Development Manual Appendix B question

Jim, 

Did you cleansstate before building and using menuconfig?  There is a bug 
(2256) that prevents configurations made using menuconfig from sticking.

Scott

-Original Message-
From: jfabernathy [mailto:jfaberna...@gmail.com] 
Sent: Tuesday, June 26, 2012 1:40 PM
To: Rifenbark, Scott M
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

On 06/26/2012 04:21 PM, Rifenbark, Scott M wrote:
> Jim,
>
> Yes - I am still running the very last part of my test.  If that is the 
> change then I will make it to the 1.2 version of the manual and publish it to 
> the website.
>
> Scott

While I had this working I thought I'd complete the Appendix B example 
for the CONFIG_SMP change.  I'm finding problems with the compile step 
after menuconfig is run to turn off SMP.  I get a mismatch that I don't 
understand:

Value requested for CONFIG_SMP not in final ".config"
Requested value: "CONFIG_SMP=y"
Actual value set: "# CONFIG_SMP is not set"

There must be another setting of CONFIG_SMP that is conflicting with the 
.config file

Jim A

> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] 
> On Behalf Of jfabernathy
> Sent: Tuesday, June 26, 2012 12:50 PM
> To: yocto@yoctoproject.org
> Subject: Re: [yocto] Yocto Development Manual Appendix B question
>
> On 06/26/2012 02:07 PM, Rifenbark, Scott M wrote:
>> When I attempted to rebuild minimal I hit the same error you did Jim 
>> regarding kern-tools-native.  This would be expected as Bruce pointed out 
>> that problem is alive in denzil.  I am going to set the poky-extras branch 
>> to 'denzil' and retry that part of the example.
>>
>> Scott
>>
>> -Original Message-
>> From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] 
>> On Behalf Of Rifenbark, Scott M
>> Sent: Tuesday, June 26, 2012 10:44 AM
>> To: Bruce Ashfield
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] Yocto Development Manual Appendix B question
>>
>> I am on task 1507 of 1606 of a minimal build (from the example).  No issues 
>> so far.
> So now that Denzil has a branch in poky-extra, the only doc change is to
> add the checkout -b denzil statement for the poky-extra directory.
> Everything else is correct.
>
> Jim A
>
>> -Original Message-
>> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
>> Sent: Tuesday, June 26, 2012 10:42 AM
>> To: Rifenbark, Scott M
>> Cc: jfabernathy; yocto@yoctoproject.org
>> Subject: Re: [yocto] Yocto Development Manual Appendix B question
>>
>> On 12-06-26 12:30 PM, Rifenbark, Scott M wrote:
>>> I am going to run through the B.1 example verbatim from the "current" 
>>> version of the manual and see what happens.
>> Fixing the license check was just a matter of me locking the SRCREV
>> for the tools to a value that works for denzil. I just pushed a denzil
>> branch to poky-extras that built and booted the yocto kernel for
>> me.
>>
>> Cheers,
>>
>> Bruce
>>
>>> Scott
>>>
>>> -Original Message-
>>> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
>>> Sent: Tuesday, June 26, 2012 9:28 AM
>>> To: Rifenbark, Scott M
>>> Cc: jfabernathy; yocto@yoctoproject.org
>>> Subject: Re: [yocto] Yocto Development Manual Appendix B question
>>>
>>> On 12-06-26 12:26 PM, Rifenbark, Scott M wrote:
 This is a good point.  In looking at the example it does not say what 
 branch you should be dealing with for poky-extras.
>>> And I'm configuring a test right now and will create a denzil
>>> branch, once I see it works.
>>>
>>> Cheers,
>>>
>>> Bruce
>>>
 -Original Message-
 From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
 Sent: Tuesday, June 26, 2012 9:24 AM
 To: jfabernathy
 Cc: Rifenbark, Scott M; yocto@yoctoproject.org
 Subject: Re: [yocto] Yocto Development Manual Appendix B question

 On 12-06-26 12:11 PM, jfabernathy wrote:
> On 06/26/2012 12:04 PM, Bruce Ashfield wrote:
>> On 12-06-26 12:00 PM, jfabernathy wrote:
>>> On 06/26/2012 10:56 AM, Rifenbark, Scott M wrote:
 Bruce,

 Should the example note this? Would it be best to specifically say to
 uncomment that SRC_URI line?

 Scott
>>> I think some text needs to be added. I uncommented the SRC_URI line and
>>> I still fail building the image. The failure is related to kernel tools:
>>>
>>> ERROR: kern-tools-native: md5 data is not matching for
>>> file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d843f43d2e22b0d91a6fee
>>>
>>>
>>> ERROR: kern-tools-native: The new md5 checksum is
>>> d8d1d729a70cd5f52972f8884b80743d
>>> ERROR: kern-tools-native: Check if the license information has
>>> changed in
>>> ERROR: Licensing Error: LIC_FILES_CHKSUM does not match, please fix
>>> ERROR: Function failed: do_qa_configure
>> This one is actually fixed on master, but poky-extras .. is just that
>

Re: [yocto] Yocto Development Manual Appendix B question

On Tue, Jun 26, 2012 at 4:40 PM, jfabernathy  wrote:
> On 06/26/2012 04:21 PM, Rifenbark, Scott M wrote:
>>
>> Jim,
>>
>> Yes - I am still running the very last part of my test.  If that is the
>> change then I will make it to the 1.2 version of the manual and publish it
>> to the website.
>>
>> Scott
>
>
> While I had this working I thought I'd complete the Appendix B example for
> the CONFIG_SMP change.  I'm finding problems with the compile step after
> menuconfig is run to turn off SMP.  I get a mismatch that I don't
> understand:
>
> Value requested for CONFIG_SMP not in final ".config"
> Requested value: "CONFIG_SMP=y"
> Actual value set: "# CONFIG_SMP is not set"
>
> There must be another setting of CONFIG_SMP that is conflicting with the
> .config file

If I'm reading this correctly, it's just another tweak needed to the
docs. When we
first wrote those sections, there were issues with the kernel
configuration audit
information being masked.

In this case the kernel configuration audit knows that your BSP wants to enable
SMP, but yet it didn't appear in the final .config, so it warns you.
But since you
manually turned it off .. this is expected.

I can't decide if we should increase complexity and detect this to
inhibit the warning,
or document it. For now, I'm in the document it camp.

Cheers,

Bruce

>
>
> Jim A
>
>> -Original Message-
>> From: yocto-boun...@yoctoproject.org
>> [mailto:yocto-boun...@yoctoproject.org] On Behalf Of jfabernathy
>> Sent: Tuesday, June 26, 2012 12:50 PM
>> To: yocto@yoctoproject.org
>> Subject: Re: [yocto] Yocto Development Manual Appendix B question
>>
>> On 06/26/2012 02:07 PM, Rifenbark, Scott M wrote:
>>>
>>> When I attempted to rebuild minimal I hit the same error you did Jim
>>> regarding kern-tools-native.  This would be expected as Bruce pointed out
>>> that problem is alive in denzil.  I am going to set the poky-extras branch
>>> to 'denzil' and retry that part of the example.
>>>
>>> Scott
>>>
>>> -Original Message-
>>> From: yocto-boun...@yoctoproject.org
>>> [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Rifenbark, Scott M
>>> Sent: Tuesday, June 26, 2012 10:44 AM
>>> To: Bruce Ashfield
>>> Cc: yocto@yoctoproject.org
>>> Subject: Re: [yocto] Yocto Development Manual Appendix B question
>>>
>>> I am on task 1507 of 1606 of a minimal build (from the example).  No
>>> issues so far.
>>
>> So now that Denzil has a branch in poky-extra, the only doc change is to
>> add the checkout -b denzil statement for the poky-extra directory.
>> Everything else is correct.
>>
>> Jim A
>>
>>> -Original Message-
>>> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
>>> Sent: Tuesday, June 26, 2012 10:42 AM
>>> To: Rifenbark, Scott M
>>> Cc: jfabernathy; yocto@yoctoproject.org
>>> Subject: Re: [yocto] Yocto Development Manual Appendix B question
>>>
>>> On 12-06-26 12:30 PM, Rifenbark, Scott M wrote:

 I am going to run through the B.1 example verbatim from the "current"
 version of the manual and see what happens.
>>>
>>> Fixing the license check was just a matter of me locking the SRCREV
>>> for the tools to a value that works for denzil. I just pushed a denzil
>>> branch to poky-extras that built and booted the yocto kernel for
>>> me.
>>>
>>> Cheers,
>>>
>>> Bruce
>>>
 Scott

 -Original Message-
 From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
 Sent: Tuesday, June 26, 2012 9:28 AM
 To: Rifenbark, Scott M
 Cc: jfabernathy; yocto@yoctoproject.org
 Subject: Re: [yocto] Yocto Development Manual Appendix B question

 On 12-06-26 12:26 PM, Rifenbark, Scott M wrote:
>
> This is a good point.  In looking at the example it does not say what
> branch you should be dealing with for poky-extras.

 And I'm configuring a test right now and will create a denzil
 branch, once I see it works.

 Cheers,

 Bruce

> -Original Message-
> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
> Sent: Tuesday, June 26, 2012 9:24 AM
> To: jfabernathy
> Cc: Rifenbark, Scott M; yocto@yoctoproject.org
> Subject: Re: [yocto] Yocto Development Manual Appendix B question
>
> On 12-06-26 12:11 PM, jfabernathy wrote:
>>
>> On 06/26/2012 12:04 PM, Bruce Ashfield wrote:
>>>
>>> On 12-06-26 12:00 PM, jfabernathy wrote:

 On 06/26/2012 10:56 AM, Rifenbark, Scott M wrote:
>
> Bruce,
>
> Should the example note this? Would it be best to specifically say
> to
> uncomment that SRC_URI line?
>
> Scott

 I think some text needs to be added. I uncommented the SRC_URI line
 and
 I still fail building the image. The failure is related to kernel
 tools:

 ERROR: kern-tools-native: md5 data is not matching for

 file://git/tools/kgit;beginline=5;endline=9;md5=

Re: [yocto] Yocto Development Manual Appendix B question

Yes - looking more closely this is not the bug issue but standard warnings.  I 
got these also.  I can put a note in the example explaining the situation. 

Scott

-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@gmail.com] 
Sent: Tuesday, June 26, 2012 1:57 PM
To: jfabernathy
Cc: Rifenbark, Scott M; yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Development Manual Appendix B question

On Tue, Jun 26, 2012 at 4:40 PM, jfabernathy  wrote:
> On 06/26/2012 04:21 PM, Rifenbark, Scott M wrote:
>>
>> Jim,
>>
>> Yes - I am still running the very last part of my test.  If that is the
>> change then I will make it to the 1.2 version of the manual and publish it
>> to the website.
>>
>> Scott
>
>
> While I had this working I thought I'd complete the Appendix B example for
> the CONFIG_SMP change.  I'm finding problems with the compile step after
> menuconfig is run to turn off SMP.  I get a mismatch that I don't
> understand:
>
> Value requested for CONFIG_SMP not in final ".config"
> Requested value: "CONFIG_SMP=y"
> Actual value set: "# CONFIG_SMP is not set"
>
> There must be another setting of CONFIG_SMP that is conflicting with the
> .config file

If I'm reading this correctly, it's just another tweak needed to the
docs. When we
first wrote those sections, there were issues with the kernel
configuration audit
information being masked.

In this case the kernel configuration audit knows that your BSP wants to enable
SMP, but yet it didn't appear in the final .config, so it warns you.
But since you
manually turned it off .. this is expected.

I can't decide if we should increase complexity and detect this to
inhibit the warning,
or document it. For now, I'm in the document it camp.

Cheers,

Bruce

>
>
> Jim A
>
>> -Original Message-
>> From: yocto-boun...@yoctoproject.org
>> [mailto:yocto-boun...@yoctoproject.org] On Behalf Of jfabernathy
>> Sent: Tuesday, June 26, 2012 12:50 PM
>> To: yocto@yoctoproject.org
>> Subject: Re: [yocto] Yocto Development Manual Appendix B question
>>
>> On 06/26/2012 02:07 PM, Rifenbark, Scott M wrote:
>>>
>>> When I attempted to rebuild minimal I hit the same error you did Jim
>>> regarding kern-tools-native.  This would be expected as Bruce pointed out
>>> that problem is alive in denzil.  I am going to set the poky-extras branch
>>> to 'denzil' and retry that part of the example.
>>>
>>> Scott
>>>
>>> -Original Message-
>>> From: yocto-boun...@yoctoproject.org
>>> [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Rifenbark, Scott M
>>> Sent: Tuesday, June 26, 2012 10:44 AM
>>> To: Bruce Ashfield
>>> Cc: yocto@yoctoproject.org
>>> Subject: Re: [yocto] Yocto Development Manual Appendix B question
>>>
>>> I am on task 1507 of 1606 of a minimal build (from the example).  No
>>> issues so far.
>>
>> So now that Denzil has a branch in poky-extra, the only doc change is to
>> add the checkout -b denzil statement for the poky-extra directory.
>> Everything else is correct.
>>
>> Jim A
>>
>>> -Original Message-
>>> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
>>> Sent: Tuesday, June 26, 2012 10:42 AM
>>> To: Rifenbark, Scott M
>>> Cc: jfabernathy; yocto@yoctoproject.org
>>> Subject: Re: [yocto] Yocto Development Manual Appendix B question
>>>
>>> On 12-06-26 12:30 PM, Rifenbark, Scott M wrote:

 I am going to run through the B.1 example verbatim from the "current"
 version of the manual and see what happens.
>>>
>>> Fixing the license check was just a matter of me locking the SRCREV
>>> for the tools to a value that works for denzil. I just pushed a denzil
>>> branch to poky-extras that built and booted the yocto kernel for
>>> me.
>>>
>>> Cheers,
>>>
>>> Bruce
>>>
 Scott

 -Original Message-
 From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
 Sent: Tuesday, June 26, 2012 9:28 AM
 To: Rifenbark, Scott M
 Cc: jfabernathy; yocto@yoctoproject.org
 Subject: Re: [yocto] Yocto Development Manual Appendix B question

 On 12-06-26 12:26 PM, Rifenbark, Scott M wrote:
>
> This is a good point.  In looking at the example it does not say what
> branch you should be dealing with for poky-extras.

 And I'm configuring a test right now and will create a denzil
 branch, once I see it works.

 Cheers,

 Bruce

> -Original Message-
> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
> Sent: Tuesday, June 26, 2012 9:24 AM
> To: jfabernathy
> Cc: Rifenbark, Scott M; yocto@yoctoproject.org
> Subject: Re: [yocto] Yocto Development Manual Appendix B question
>
> On 12-06-26 12:11 PM, jfabernathy wrote:
>>
>> On 06/26/2012 12:04 PM, Bruce Ashfield wrote:
>>>
>>> On 12-06-26 12:00 PM, jfabernathy wrote:

 On 06/26/2012 10:56 AM, Rifenbark, Scott M wrote:
>
> Bruce,
>
> Should the example note this? Would it be best to specifical

[yocto] Git fetcher error