Date   

The simplest possible recipe

Paul D. DeRocco
 

That would be to copy a single file, provided in the files subdirectory of
the recipe, into a particular place in the target tree. Is there any bbclass
that automates this? Or do I just write a recipe with a do_install function
that executes the "install" command?

My only guide is 5.3.1 in the Development Manual, which performs a simple
compilation, but I'm very hazy about how recipes are interpreted, so I'd
like it if someone can tell me if I've gotten the following stuff right or
not.

SRC_URI tells bitbake what files must be gotten from somewhere and copied
somewhere else in order to carry out the build process. And according to the
Ref Manual, the "file://" prefix tells it to fetch a local file by searching
some directories including the "files" subdirectory next to the .bb file.
And apparently, there is a "subdir" option (whose syntax is unexplained)
which may be used to tell bitbake to put it somewhere specific relative to
${WORKDIR}.

Is the default value of the "subdir" option the S variable? Is that the
purpose of S, to tell bitbake where to put things that it fetches? The Ref
Manual says that S defaults to ${WORKDIR}/${PN}/${PV}, but then the sample
compile recipe sets S to ${WORKDIR}. Is that what one does when one doesn't
need to have a bunch of versioned subdirectories under ${WORKDIR}? (I'm not
sure why one would ever want that, or why that would be the default.)

So if I want to install a file somewhere, do I even need a do_install task,
or can I just set S equal to the desired target location, like
"${etcdir}/foo" and be done with it? Or is that a no-no, and should I always
use do_install?

--

Ciao, Paul D. DeRocco
Paul mailto:pderocco@ix.netcom.com


Re: Yocto Project bug trends for 2013 WW25

David Stewart
 

Thanks for sending these out! Nice to see it before the meeting tomorrow

On 6/24/13 11:37 AM, "Michael Halstead" <michael@yoctoproject.org> wrote:

The trend graphs for work week 25 are up at
https://wiki.yoctoproject.org/wiki/Yocto_Bug_Trend with two new charts.
Versions of the weighted defect density trend-lines with Yocto Project
release dates and several additional controls have been added.

Screenshots of the graphs are attached for people who need a copy while
offline. These are large images and you may need to open them outside of
your e-mail client to see all the detail.

--
Michael Halstead
Yocto Project / System Administrator


Yocto Project bug trends for 2013 WW25

Michael Halstead
 

The trend graphs for work week 25 are up at
https://wiki.yoctoproject.org/wiki/Yocto_Bug_Trend with two new charts.
Versions of the weighted defect density trend-lines with Yocto Project
release dates and several additional controls have been added.

Screenshots of the graphs are attached for people who need a copy while
offline. These are large images and you may need to open them outside of
your e-mail client to see all the detail.

--
Michael Halstead
Yocto Project / System Administrator


Re: Documenting YP Development Environment in more detail - user configuration

Jeff Osier-Mixon <jefro@...>
 

On Mon, Jun 24, 2013 at 11:25 AM, Philip Balister <philip@balister.org> wrote:
Showing how Poky (the reference distribution) is built would be a nice
way to introduce people to building their own custom distributions using
OpenEmbedded.
Totally agree, but I would relegate that to a separate effort. The
main problem with diagrams like this is trying to squeeze in too much
information in order to preserve completeness, at the expense of
clarity. It would be more ideal to start with a very simple diagram,
then move on to other diagrams to zoom in on pertinent detail. It is a
delicate balancing act. In this case, I would say to put "how Poky is
built" into the 3rd or 4th diagram in a series.

I'm glad to see this conversation happening!

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


Re: Documenting YP Development Environment in more detail - user configuration

Philip Balister
 

On 06/24/2013 12:59 PM, Burton, Ross wrote:
On 24 June 2013 17:55, Philip Balister <philip@balister.org> wrote:
Explaining how poky is built up from oe-core + meta-yocto +
meta-yocto-bsp + some other stuff would be really helpful in reducing
confusion over what all the pieces are and where they come from.
Agreed - explaining clearly that Poky is mostly an aggregation of
existing repositories and not actually canonical upstream for anything
is probably a good move, as this is clearly misunderstood by many
people.
Showing how Poky (the reference distribution) is built would be a nice
way to introduce people to building their own custom distributions using
OpenEmbedded.

Philip


Re: Documenting YP Development Environment in more detail - user configuration

Rifenbark, Scott M <scott.m.rifenbark@...>
 

Ok - I was told there was just a single version of oe-init-build-env. So that must be not quite right. What I will likely do is in the supporting text for the figure get into some detail on just where these pieces are. That would be a good opportunity to maybe present some text around that.

-----Original Message-----
From: Philip Balister [mailto:philip@balister.org]
Sent: Monday, June 24, 2013 9:56 AM
To: Rifenbark, Scott M
Cc: Burton, Ross; Robert P. J. Day; yocto@yoctoproject.org
Subject: Re: [yocto] Documenting YP Development Environment in more
detail - user configuration

On 06/24/2013 11:08 AM, Rifenbark, Scott M wrote:
My figure is for Yocto Project documentation so I am going to show
that oe-init-build-env gets information from meta-yocto. I understand
that OE-Core sample files are in "meta". There is a single oe-init-
build-env script and it looks in one of two places.

Actually, the script is in two places, the root level of a poky checkout
and in the oe-core directory.

Explaining how poky is built up from oe-core + meta-yocto +
meta-yocto-bsp + some other stuff would be really helpful in reducing
confusion over what all the pieces are and where they come from.

Philip


Scott

-----Original Message-----
From: Burton, Ross [mailto:ross.burton@intel.com]
Sent: Monday, June 24, 2013 7:57 AM
To: Robert P. J. Day
Cc: Rifenbark, Scott M; yocto@yoctoproject.org
Subject: Re: [yocto] Documenting YP Development Environment in more
detail - user configuration

On 24 June 2013 15:47, Robert P. J. Day <rpjday@crashcourse.ca>
wrote:
On Mon, 24 Jun 2013, Rifenbark, Scott M wrote:

What I was trying to convey here is that oe-init-build-env draws on
some files in the meta-yocto layer. The script oe-init-build-env
is
in the poky repository (or refered to as "Source Directory" in the
documentation). The sample files are in the meta-yocto layer. I
thought the meta-yocto layer was needed... maybe I am wrong. Can I
get more clarification on this?
i regularly build images without any "*yocto*"-named layer, unless
i'm misunderstanding the issue here.
meta-yocto is what makes Poky Poky, otherwise it would be just oe-
core
+ bitbake. oe-init-build-env looks for sample files in
$TEMPLATECONF,
which is one of the things that get munged as
bitbake+oe-core+meta-yocto becomes poky.

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


Re: Documenting YP Development Environment in more detail - user configuration

Ross Burton
 

On 24 June 2013 17:55, Philip Balister <philip@balister.org> wrote:
Explaining how poky is built up from oe-core + meta-yocto +
meta-yocto-bsp + some other stuff would be really helpful in reducing
confusion over what all the pieces are and where they come from.
Agreed - explaining clearly that Poky is mostly an aggregation of
existing repositories and not actually canonical upstream for anything
is probably a good move, as this is clearly misunderstood by many
people.

Ross


Re: Documenting YP Development Environment in more detail - user configuration

Philip Balister
 

On 06/24/2013 11:08 AM, Rifenbark, Scott M wrote:
My figure is for Yocto Project documentation so I am going to show that oe-init-build-env gets information from meta-yocto. I understand that OE-Core sample files are in "meta". There is a single oe-init-build-env script and it looks in one of two places.
Actually, the script is in two places, the root level of a poky checkout
and in the oe-core directory.

Explaining how poky is built up from oe-core + meta-yocto +
meta-yocto-bsp + some other stuff would be really helpful in reducing
confusion over what all the pieces are and where they come from.

Philip


Scott

-----Original Message-----
From: Burton, Ross [mailto:ross.burton@intel.com]
Sent: Monday, June 24, 2013 7:57 AM
To: Robert P. J. Day
Cc: Rifenbark, Scott M; yocto@yoctoproject.org
Subject: Re: [yocto] Documenting YP Development Environment in more
detail - user configuration

On 24 June 2013 15:47, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
On Mon, 24 Jun 2013, Rifenbark, Scott M wrote:

What I was trying to convey here is that oe-init-build-env draws on
some files in the meta-yocto layer. The script oe-init-build-env is
in the poky repository (or refered to as "Source Directory" in the
documentation). The sample files are in the meta-yocto layer. I
thought the meta-yocto layer was needed... maybe I am wrong. Can I
get more clarification on this?
i regularly build images without any "*yocto*"-named layer, unless
i'm misunderstanding the issue here.
meta-yocto is what makes Poky Poky, otherwise it would be just oe-core
+ bitbake. oe-init-build-env looks for sample files in $TEMPLATECONF,
which is one of the things that get munged as
bitbake+oe-core+meta-yocto becomes poky.

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


Re: linux-libc-header version mismatch?

Hans Beckérus <hans.beckerus@...>
 

On Mon, Jun 24, 2013 at 6:29 PM, Paul Barker <paul@paulbarker.me.uk> wrote:
On 24 June 2013 17:19, Bruce Ashfield <bruce.ashfield@windriver.com> wrote:
On 13-06-24 11:59 AM, Hans Beckérus wrote:

Hi. We are using a 3.6 based kernel in our builds using a custom
kernel recipe. However, I can see that the linux-libc-headers built
but based on a 3.8 kernel?
Is this really how it should be? Are we supposed to also make a custom
recipe for the linux-libc-headers? The image seems to be executing
fine but I am a bit worried about the version mismatch :(
Summary: you can match them if you want, but we are testing across
several kernel versions and haven't found any issues (yet).
Just to point out - this is pretty common across linux distros as
well, otherwise all your software would have to be re-built every time
you updated the kernel.

--
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk
Thanks Paul (and Bruce of course).
I now realize that this would break most systems after a major kernel upgrade ;)
From what I know/experienced so far is that the only thing that
usually breaks with a new major kernel version is our own kernel
drivers...

Hans


On Mon, Jun 24, 2013 at 6:29 PM, Paul Barker <paul@paulbarker.me.uk> wrote:
On 24 June 2013 17:19, Bruce Ashfield <bruce.ashfield@windriver.com> wrote:
On 13-06-24 11:59 AM, Hans Beckérus wrote:

Hi. We are using a 3.6 based kernel in our builds using a custom
kernel recipe. However, I can see that the linux-libc-headers built
but based on a 3.8 kernel?
Is this really how it should be? Are we supposed to also make a custom
recipe for the linux-libc-headers? The image seems to be executing
fine but I am a bit worried about the version mismatch :(
Summary: you can match them if you want, but we are testing across
several kernel versions and haven't found any issues (yet).
Just to point out - this is pretty common across linux distros as
well, otherwise all your software would have to be re-built every time
you updated the kernel.

--
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk


Re: linux-libc-header version mismatch?

Paul Barker <paul@...>
 

On 24 June 2013 17:19, Bruce Ashfield <bruce.ashfield@windriver.com> wrote:
On 13-06-24 11:59 AM, Hans Beckérus wrote:

Hi. We are using a 3.6 based kernel in our builds using a custom
kernel recipe. However, I can see that the linux-libc-headers built
but based on a 3.8 kernel?
Is this really how it should be? Are we supposed to also make a custom
recipe for the linux-libc-headers? The image seems to be executing
fine but I am a bit worried about the version mismatch :(
Summary: you can match them if you want, but we are testing across
several kernel versions and haven't found any issues (yet).
Just to point out - this is pretty common across linux distros as
well, otherwise all your software would have to be re-built every time
you updated the kernel.

--
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk


Re: linux-libc-header version mismatch?

Bruce Ashfield <bruce.ashfield@...>
 

On 13-06-24 11:59 AM, Hans Beckérus wrote:
Hi. We are using a 3.6 based kernel in our builds using a custom
kernel recipe. However, I can see that the linux-libc-headers built
but based on a 3.8 kernel?
Is this really how it should be? Are we supposed to also make a custom
recipe for the linux-libc-headers? The image seems to be executing
fine but I am a bit worried about the version mismatch :(
You shouldn't need to do this. We use a single libc-headers version
for all of a given linux-yocto kernels in a release. The userspace /
libc ABI is stable, and backwards compatible (generally speaking of
course). New interfaces typically have a fallback if the kernel
interface is missing, and we don't currently have any issues either.

Of course older headers with newer kernels is even safer, since
typically at most you are missing out on being able to use new APIs
versus potential for missing APIs.

Summary: you can match them if you want, but we are testing across
several kernel versions and haven't found any issues (yet).

Cheers,

Bruce


Hans

PS. I believe I posted this question before but I am no longer 100%
convinced it actually left my outbox. At least I never got a response,
which usually happens very quickly :)
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [PATCHv2 0/8][eclipse-poky] Add target profile quick switch

Zhang, Jessica
 

Hi Timo,

Your finding is described in my case 3. For reproduce the double selection, you need to select "project specific" apply exit the property window. Then go back to property window, deselect "project specific" apply, exit the window. Then check the drop down list, I can consistently reproduce the case this way. Give it a try.

Thanks,
Jessica

-----Original Message-----
From: Timo Müller [mailto:mail@timomueller.eu]
Sent: Sunday, June 23, 2013 11:52 PM
To: Zhang, Jessica
Cc: yocto@yoctoproject.org; Timo Mueller
Subject: Re: [yocto] [PATCHv2 0/8][eclipse-poky] Add target profile quick switch

Hi Jessica

Zhang, Jessica wrote, On 24.06.2013 07:25:
Hi Timo,

For case 1, I think we probably should bring back the grey out option.
In my opinion, it's more consistent. The property window should be
the centralized place for user to setup the settings. The drop down
list is for user to quickly toggle between the different settings. So
the behavior should be:

If there's no project specific settings, that option will be greyed
out. I don't think it'll make it secondary as long as it's still
visible. Once user 1st time check the project specific setting in the
project properties window, we copy the prior profile settings as start
point then the user can further customize if there's the need.
Once a project has its own specific settings, the option will be
enabled in the drop down list and the selection will be consistent
between the drop down list selection and project properties settings.

What do you think?
I get your point. I'll kick out the last patch to restore the greyed out version.

I tried to reproduce case 3. And I haven't been able to bring the menu to a state where two menu items are checked. I tried all sorts of combinations without success. Could you maybe tell me the exact steps on how you get this behaviour?

However, when trying the different options I realized that there's a bug in the project preferences. Maybe you've already pointed it out and I didn't get it. But if you've configured a project specific profile and change to a target profile, when you enable the project specific profile again, your settings are lost. Instead the selected profile is copied all of the time, instead of only at the first time of configuration.

I'll send a fix and a v3 of the menu with the greyed out menu item.


Jessica -----Original Message----- From: Timo Mueller
[mailto:mail@timomueller.eu] Sent: Sunday, June 23, 2013 1:36 AM To:
Zhang, Jessica Cc: yocto@yoctoproject.org; Timo Mueller Subject: Re:
[yocto] [PATCHv2 0/8][eclipse-poky] Add target profile quick switch

Hi Jessica,

Am 21.06.2013 23:47, schrieb Zhang, Jessica:
Hi Timo,

So what's the purpose of "Project Specific Settings", my >
understanding is it's something that only local to project instead of
global name space, e.g. profile?
Yes, that's the main idea.

OK, I've played a little bit of toggling between profiles, and
project specific setting and notice > the following behaviors that
can be confusing:

1. As your preference that user can specify "project specific >
settings". I've noticed for this case, if I haven't entered any >
project specific settings via the preference wizard, it'll always
copy the profile settings prior to its selection, then in this
case I > don't think it makes much sense since we already have the
profiles to > cover all the settings
That's independent of this patch set, right?

The original idea behind copying the settings of the currently
selected profile was to give the user a starting point for creating
the project specific settings. The assumption was that the user most
of the times only does small modifications to an existing profile.

Sure, if the user doesn't alter the settings, the project specific
ones match an already defined target profile. One difference remains,
if he changes the target profile it will update all projects that use
this profile. The project that is using it's own configuration won't
be changed, although the settings are similar.

An alternative to copying the inital settings would be to blank out
the form, when the checkbox is checked. If the assumption is not
correct and we think that this is easier to understand for the user,
I'll provide a patch set changing this behaviour.


2. OK, now let's move to the case of that I do have explicit setup a
project specific settings in the project property view apply it and
exit the window. After that, in the drop down list, when I toggle
between the options, e.g. I have two profiles besides the project
specific settings, then every time after I made the selection and
check in the project properties view, the settings matches my >
selection. So this is good and consistent behavior.

3. If inside the project properties window, I uncheck the "Use >
project specific settings" box, and select a profile then apply the
changes close the window. Now in the drop down list I will see
both > the "project specific setting" and the selected profile are
selected. Then next time when I go back, and re-check "Use project
specific > settings" box, my project specific setting will be gone,
instead the > settings will show as my previous profile settings.
That's a bug in my implementation. They should always be in sink as
you explained in your second point.


Overall, I think we still need to play a little bit more of different
setting selections via different approaches, some of the
inconsistent > behavior can get user lost.

Thanks, Jessica -----Original Message----- From:
yocto-bounces@yoctoproject.org
[mailto:yocto-bounces@yoctoproject.org] On Behalf Of Timo Mueller
Sent: Friday, June 21, 2013 5:45 AM To: yocto@yoctoproject.org
Cc: Timo Mueller Subject: [yocto] [PATCHv2 0/8][eclipse-poky] Add
target > profile quick switch > > From: Timo Mueller
<timo.mueller@bmw-carit.de> > > Changes in v2: Handle error when
project specific profile is not > configured more gracefully.
Instead of showing an error message the > button is now greyed out.

Patches 01..07 contain the implementation with the greyed out menu
button.
After playing around with the two options discussed in the first >
patch series, I started to prefer inserting a different button in the
menu allowing the user to quickly navigate to the project
preferences > instead of just greying it out. I've added this in the
last patch of > the series, so you can compare yourself.

From original cover letter <snip> if a user wants to change the used
target profile of a project he currently has to open the project >
preferences. This can be tedious if he has to switch the profile >
often.

This is a small addition which allows the user to quickly switch the
used target profile of a project. Instead of having to open the >
project preferences the user can select the project in the navigator
and then choose the desired target profile from a drop-down menu in
the toolbar or from the project menu. </snip>
> 01: Small i18n fix 02..04: Refactoring the project specific
utils > 05..06: Introduce the target profile toolbar switch 07:
Adds the > target profile switch to the project menu 08:
Experimental: Add > button to open project preferences > > Best
regards, Timo
Thanks, for the input. I'll fix the bug and send a v3.

Best regards, Timo
Best regards,
Timo


linux-libc-header version mismatch?

Hans Beckérus <hans.beckerus@...>
 

Hi. We are using a 3.6 based kernel in our builds using a custom
kernel recipe. However, I can see that the linux-libc-headers built
but based on a 3.8 kernel?
Is this really how it should be? Are we supposed to also make a custom
recipe for the linux-libc-headers? The image seems to be executing
fine but I am a bit worried about the version mismatch :(

Hans

PS. I believe I posted this question before but I am no longer 100%
convinced it actually left my outbox. At least I never got a response,
which usually happens very quickly :)


Re: Image recipes in Yocto 1.4 (dylan-9.0.0)

Paul Eggleton
 

Hi Brian,

On Monday 24 June 2013 11:01:31 Brian Karcz wrote:
I have a question regarding the shared state code optimizations in yocto
1.4. I'm in the process of upgrading one of our projects from Edison (6.0)
to Dylan (9.0.0) and am running into an issue with our existing image
recipe.

The recipe brings in files from a "files" directory in the image area. It
also adds an image preprocess command that takes action on those files in
the work area. After reading the version 1.4 migration guidelines and
examining both the old and new builds, it looks like the do_unpack task has
been optimized out of the way images are built in the new release. The
files listed in the SRC_URI variable don't get populated in the work
directory, and actions taken in the image preprocess command fail.

Is there a way to stop this optimization and have the image build populate
the work directory as it has in the past?
You should be able to do this in your image recipe:

python () {
d.delVarFlag("do_fetch", "noexec")
d.delVarFlag("do_unpack", "noexec")
}

This isn't related to shared state, btw, just that image.bbclass disables
these tasks by default as of version 1.2 (denzil).

Cheers,
Paul


--

Paul Eggleton
Intel Open Source Technology Centre


Re: Documenting YP Development Environment in more detail - user configuration

Rifenbark, Scott M <scott.m.rifenbark@...>
 

My figure is for Yocto Project documentation so I am going to show that oe-init-build-env gets information from meta-yocto. I understand that OE-Core sample files are in "meta". There is a single oe-init-build-env script and it looks in one of two places.

Scott

-----Original Message-----
From: Burton, Ross [mailto:ross.burton@intel.com]
Sent: Monday, June 24, 2013 7:57 AM
To: Robert P. J. Day
Cc: Rifenbark, Scott M; yocto@yoctoproject.org
Subject: Re: [yocto] Documenting YP Development Environment in more
detail - user configuration

On 24 June 2013 15:47, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
On Mon, 24 Jun 2013, Rifenbark, Scott M wrote:

What I was trying to convey here is that oe-init-build-env draws on
some files in the meta-yocto layer. The script oe-init-build-env is
in the poky repository (or refered to as "Source Directory" in the
documentation). The sample files are in the meta-yocto layer. I
thought the meta-yocto layer was needed... maybe I am wrong. Can I
get more clarification on this?
i regularly build images without any "*yocto*"-named layer, unless
i'm misunderstanding the issue here.
meta-yocto is what makes Poky Poky, otherwise it would be just oe-core
+ bitbake. oe-init-build-env looks for sample files in $TEMPLATECONF,
which is one of the things that get munged as
bitbake+oe-core+meta-yocto becomes poky.

Ross


Image recipes in Yocto 1.4 (dylan-9.0.0)

Brian Karcz <briank@...>
 

Hi,

 

I apologize in advance if I’m not posting this to correct place or in the correct manner.

 

I have a question regarding the shared state code optimizations in yocto 1.4. I’m in the process of upgrading one of our projects from Edison (6.0) to Dylan (9.0.0) and am running into an issue with our existing image recipe.

 

The recipe brings in files from a “files” directory in the image area. It also adds an image preprocess command that takes action on those files in the work area. After reading the version 1.4 migration guidelines and examining both the old and new builds, it looks like the do_unpack task has been optimized out of the way images are built in the new release. The files listed in the SRC_URI variable don’t get populated in the work directory, and actions taken in the image preprocess command fail.

 

Is there a way to stop this optimization and have the image build populate the work directory as it has in the past?

 

Thank you,

Brian


Re: Documenting YP Development Environment in more detail - user configuration

Ross Burton
 

On 24 June 2013 15:47, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
On Mon, 24 Jun 2013, Rifenbark, Scott M wrote:

What I was trying to convey here is that oe-init-build-env draws on
some files in the meta-yocto layer. The script oe-init-build-env is
in the poky repository (or refered to as "Source Directory" in the
documentation). The sample files are in the meta-yocto layer. I
thought the meta-yocto layer was needed... maybe I am wrong. Can I
get more clarification on this?
i regularly build images without any "*yocto*"-named layer, unless
i'm misunderstanding the issue here.
meta-yocto is what makes Poky Poky, otherwise it would be just oe-core
+ bitbake. oe-init-build-env looks for sample files in $TEMPLATECONF,
which is one of the things that get munged as
bitbake+oe-core+meta-yocto becomes poky.

Ross


Re: Documenting YP Development Environment in more detail - user configuration

Robert P. J. Day
 

On Mon, 24 Jun 2013, Rifenbark, Scott M wrote:

What I was trying to convey here is that oe-init-build-env draws on
some files in the meta-yocto layer. The script oe-init-build-env is
in the poky repository (or refered to as "Source Directory" in the
documentation). The sample files are in the meta-yocto layer. I
thought the meta-yocto layer was needed... maybe I am wrong. Can I
get more clarification on this?
i regularly build images without any "*yocto*"-named layer, unless
i'm misunderstanding the issue here.

rday

--

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

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


Re: Documenting YP Development Environment in more detail - user configuration

Rifenbark, Scott M <scott.m.rifenbark@...>
 

What I was trying to convey here is that oe-init-build-env draws on some files in the meta-yocto layer. The script oe-init-build-env is in the poky repository (or refered to as "Source Directory" in the documentation). The sample files are in the meta-yocto layer. I thought the meta-yocto layer was needed... maybe I am wrong. Can I get more clarification on this?

Thanks,
Scott

-----Original Message-----
From: Philip Balister [mailto:philip@balister.org]
Sent: Monday, June 24, 2013 6:15 AM
To: Rifenbark, Scott M
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Documenting YP Development Environment in more
detail - user configuration

On 06/23/2013 11:52 PM, Rifenbark, Scott M wrote:
Hi,

I am going to start throwing these diagrams out to the mailing list
and see if I can get any feedback. This attached figure dives into user
configuration. Any and all discussion, correction, suggestions are
welcome.

It appears the diagram says that the oe-init-build-env script creates
the files in the users conf dir from the meta-yocto layer. These files
(and the script) are in meta. This diagram creates the misleading idea
that the meta-yocto layer is mandatory in order to create a working
build.

Philip


Scott

-----Original Message-----
From: Rifenbark, Scott M
Sent: Friday, June 21, 2013 1:22 AM
To: Paul Eggleton; Burton, Ross
Subject: user configuration

Paul and Ross,

Attached is a sample figure that focuses on "User Configuration."
The
illustration attempts to reveal where user configuration data comes
from
and what processes and user-driven commands are related to it. Right
now, BitBake is simply a box.

If you can, give me some comments on this. I would like to hear on
level of detail as well as technical accuracy.

Thanks,
Scott

Scott Rifenbark
Intel Corporation
Yocto Project Documentation
503.712.2702
503.341.0418 (cell)


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


Re: Documenting YP Development Environment in more detail - user configuration

Rifenbark, Scott M <scott.m.rifenbark@...>
 

Jerrod,

 

Thanks for the feedback in this area.  Your observations are pretty much in line with what I got from Paul Eggleton, who is on the YP Team.  I am going to reduce what is revealed file-wise in the meta-yocto layer.  Turns out that auto.conf and site.conf are files that a user would have to hand-create if they even wanted them.  We happen to provide a sample for site.conf only.  The auto.conf file would be a file that could be created and written to by an autobuilder.  The auto.conf file could contain settings that would be similar to what you would see in a local.conf file.  My understanding is that it exists mainly for autobuilders to stuff things into.  I will note this in the section I’m developing here for this configuration stuff. 

 

Machine, distro, and policies and all that type of configuration is going to be covered in my next little submission that talks about layers and their role regarding what they feed into the whole process.

 

Thanks,

Scott

 

From: Jerrod Peach [mailto:peachj@...]
Sent: Monday, June 24, 2013 6:00 AM
To: Rifenbark, Scott M
Cc: yocto@...
Subject: Re: [yocto] Documenting YP Development Environment in more detail - user configuration

 

Scott,

 

I think the general diagram looks pretty good, although I'd argue there's a little too much detail in the file list being shown, or else some of this new stuff is going to be useful in 1.5 when it's not doing anything in 1.4.  Here are the files I see as excessive:

 

In meta-yocto:

  • local.conf.example.extended
  • site.conf.sample
  • auto.conf (That's not even present in my 1.4 workspace.  Is this going to be something new in 1.5?)

In the build directory (these files aren't even present for me in 1.4):

  • site.conf
  • auto.conf

Also, I don't see anything specifying machines.  Do you want to break that out here, or are you thinking that's going to come into play somewhere else?  If you're thinking of breaking out machines elsewhere, I'd argue that distros are on a similar level of detail and then also don't belong on this chart.

 

Kind regards,

 

Jerrod

 

On Sun, Jun 23, 2013 at 11:52 PM, Rifenbark, Scott M <scott.m.rifenbark@...> wrote:

Hi,

I am going to start throwing these diagrams out to the mailing list and see if I can get any feedback.  This attached figure dives into user configuration.  Any and all discussion, correction, suggestions are welcome.

Scott

>-----Original Message-----
>From: Rifenbark, Scott M
>Sent: Friday, June 21, 2013 1:22 AM
>To: Paul Eggleton; Burton, Ross
>Subject: user configuration
>
>Paul and Ross,
>
>Attached is a sample figure that focuses on "User Configuration."  The
>illustration attempts to reveal where user configuration data comes from
>and what processes and user-driven commands are related to it.  Right
>now, BitBake is simply a box.
>
>If you can, give me some comments on this.  I would like to hear on
>level of detail as well as technical accuracy.
>
>Thanks,
>Scott
>
>Scott Rifenbark
>Intel Corporation
>Yocto Project Documentation
>503.712.2702
>503.341.0418 (cell)


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