[yocto] Understanding the git commits for Yocto and meta

[Bruce Ashfield]

On Sun, Jan 29, 2012 at 7:00 AM, James Abernathy <jfabernathy at gmail.com> wrote:
>
> On Jan 28, 2012, at 6:25 PM, Bruce Ashfield wrote:
>
> On Sat, Jan 28, 2012 at 9:51 AM, James Abernathy <jfabernathy at gmail.com>
> wrote:
>
> While I've read enough to think I understand git, I get confused when it's
>
> applied to real situations like Yocto.  If I look at the Yocto Development
>
> Manual, Appendix A, A.5.2.4 Changing Recipes-kernel, It brings up some
>
> questions.
>
>
> 1. The way I see it, when you guys commit something to the linux yocto
>
> master or meta there is a commit string associated with that commit.  Not to
>
> any certain branch of the git repository, right?
>
>
> I'm not following your terminology. There's a git has that is used to
> update the SRCREVs
> for bitbake, but that hash is always on the meta branch. Bitbake likes
> git hashes, but the
> kernel build infrastructure talks branches .. since humans can
> remember branches, but
> not git hashes.
>
>
> I'm sure I'm not using the terminology right because, I clearly don't
> understand the whole concept yet.  That light bulb has not gone on yet. :-)

The quoting is all messed up in my copy of the email, so apologies if I miss
something on my reply!

>
> Basically, I see from a user perspective that you start the process with
> creating a clone of the Yocto Project files
> repository, git://git.yoctoproject.org/poky, and you also create a clone of
> the meta-intel BSP repository if you are working with the Intel board BSPs.
>  I have on occasion also cloned the Yocto Linux Kernel and poky extra so I
> could do the Appendix B example.  In the examples and my testing, I've
> always checked out the edison branch of both the yocto project files in the
> poky directory and the edison branch in the meta-intel directory.  So in my
> primitive  thinking, my branch is edison.  By examining Appendix B, I see
> where they checkout a branch of the Yocto Linux kernel called,
> common-pc-base, using the command, git checkout -b common-pc-base
> origin/yocto/standard/common-pc/base.  But once changes are made you commit
> those changes to the local bare clone that will be used in the build
> process.  So I think I see that to get the right versions of the Yocto Linux
> Kernel, I need to tell bitbake to use a particular branch called
> yocto/standard/common-pc/base.  I think the KMACHINE parameter does this in

It's less "version" and more "right branch for my machine", using the
repository that
was current / specified in the yocto release you are working from.
i.e. edison had
2.6.37 and 3.0 kernels, and the meta/recipes-kernel/linux/linux-yocto*
recipes point
to the right repositories that are known to work for that release, and
the recipes specify
the SRCREVs for the machine and meta branches.

> the Appendix B example.  However, in the App. B example, there is no talk
> about SRCREV anywhere.

That's all correct. The appendix examples typically have a setup that
uses AUTOREV
during local kernel development. This means that you don't need to do
SRCREV updates
to see you changes. If you weren't working with AUTOREV, you would need to have
SRCREV updates in a bbappend in the layer of your choice.

> Relating Appendix A recipes-kernel SRCREV to Appendix B example is a problem
> for me.
>
>
>
> 2.  So if I'm building an image for atom-pc using Edison branch, the first
>
> SRCREV I'm interested in is yocto/standard/common-pc/atom-pc branch.  But
>
> the commits I see at
>
>
>  http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/commit/?h=yocto/standard/common-pc/atom-pc
>
>
> are commits not associated with Edison, but Master, right?

They are associated with the 3.0  kernel development. master points at
certain SRCREVs, older
releases have SRCREVs that mark where we tested them. Also note that
as development marches
on for a given kernel version it is done in such a way that the older
release continues to work, with
the same machine branches, just building different points in those
branches (the SRCREVs). If we
add functionality to a kernel that isn't appropriate for a point
release (i.e. 1.1.1) then a maintenance
copy of the repository is created, and the point release branch
recipes are updated to point to that
repository.

>
>
> They are all just commits on the board branch. edison has a snapshot
> in time the SRCREV
> that is used. Master marches on, but the commits that were current in
> the timeframe of edison,
> will always be there.

Exactly.

>
>
> So here is a terminology problem in my mind.
>  yocto/standard/common-pc/atom-pc seems to be a branch in the meta-intel
> repository.  edison seems to be both a snapshot and branch of poky
> repository.???

Richard probably has the right terminology here, but edison is a yocto
release branch,
which happens in the poky.git repository. The kernel branches are just
that, kernel
branches, and the repositories are associated with yocto releases.

>
> For example, at , http://git.yoctoproject.org/cgit/cgit.cgi/, I see Poky
> listed. clicking on Poky, http://git.yoctoproject.org/cgit/cgit.cgi/poky/, I
> go to a summary page that shows edison as a branch of poky. If I look at the
> log and commit tabs on that page I see that Scott Rifenbark had a patch that
> got committed most recently in November:
>
> author Scott Rifenbark <scott.m.rifenbark at intel.com>2011-11-23 18:58:23
> (GMT)
> committer Richard Purdie <richard.purdie at linuxfoundation.org>2011-11-25
> 15:26:48 (GMT)
> commit adcf8bf7b52460b94998438e8c2bf854cdec0a80 (patch) (side-by-side diff)
> tree 02cb7ae971dce7e464b31cdd88d47bc710f0c1e4
> parent fda17235fdba53583b5a0ed8187021cd5c093a09 (diff)
> download poky-edison.zip
> poky-edison.tar.gz
> poky-edison.tar.bz2
>
> So that tells me that If I sticking to edison for everything related to
> poky, then I need to use this commit string to get the latest Edison Poky
> patches, Am I right???
> Where do I put that or is the fact that I checked out edison branch and did
> a recent pull make me current with respect to poky???

It's this. The fact that you checked out edison, gets you what you want. The
HEAD of the edison branch is that commit, and that's what you'll get and build.

>
> So basically, in Appendix A Recipes-kernel section.  what exactly are the
> SRCREV statements telling Bitbake and why are there 2 of them.

SRCREVs are what recipes that track upstream projects via their SCM use to
specify exactly what to build. poky itself isn't tracked by SRCREVs,
since it isn't
a recipe .. it's the project.

The two kernel SRCREVS are what we were discussion, the two of them describe
the configuration for a board (the meta branch) and the code/content (the board
branch). We use them to make sure you get exactly what you expect from
the kernel
repository when you build.

>
> Thanks,
>
>
>
> 3.  How do I find the commit string for a particular branch, like Edison,
>
> for something like yocto/standard/common-pc/atom-pc?
>
>
> I'm not following the terminology again. Maybe if you describe what
> you are trying to
> achieve ? git will tell you what branch has any commit .. just use git
> branch --contains <hash>
>
>
> 4.  To me, branches are things like Edison, Bernard, etc.  But on the page:
>
>
> http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/refs/heads?h=yocto/standard/common-pc/atom-pc
>
>
> yocto/standard/common-pc/atom-pc, master, and meta are all listed as
>
> branches.  What is the difference??
>
>
> edison and bernard are yocto branches. The kernel is a separate
> repository and can actually be
> used standalone (which I do). It has branches for it's meta data and
> to isolate board changes.
> A particular kernel repository is referenced by the yocto kernel
> recipes. They are what follow the
> yocto branches .. not the kernel itself.
>
>
> I think I see part of my problem.  (Other than too much bourbon over the
> last 40 years)
> The Yocto project (poky) repository has edison, bernard, master as branches
> of that repository. I need to keep that thinking separate from the
> meta-intel repository where edison and bernard are also branches.
>
> Plus, the yocto linux kernel is yet another git repository which has
> branches like meta, crownbay, common-pc, etc??  did I get that right??  is
> this the only part that needs a SRCREV??

Correct. Separate repositories, that can have separate branching
strategies and if it is
part of a recipe (the kernel), the right part of it to build is
tracked via SRCREVs.

>
>
>
>
> 5.  The second SRCREV seems to be associated with meta.  How does that
>
> relate to my whole confusion on branches.
>
>
> A board build is composed of two things the meta data (configuration,
> patches) that
> describe the BSP and the actual code changes (the board branch).
>
>
> So in the Appendix A example, which SRCREV is tied to what?  Below is the
> 1st SRCREV for the board branch(actual code changes)? and the Second one the
> Meta data?:

Correct. I'll ramble below.

>
>  COMPATIBLE_MACHINE_mymachine = "mymachine"
>      KMACHINE_mymachine  = "yocto/standard/common-pc/atom-pc"
>      KERNEL_FEATURES_append_mymachine += " cfg/smp.scc"
>
>      SRCREV_machine_pn-linux-yocto_mymachine ?= \
>         "1e18e44adbe79b846e382370eb29bc4b8cd5a1a0"

The ''machine' branch is the yocto/standard/<BSP> branch. As I hinted
at, a person could work
completely via SRCREVs, but the yocto kernel build infrastructure
likes to talk branches and is
used in multiple build systems .. that and humans can remember branch
names better than
git hashes. So both are specified, the branches and the SRCREV.
bitbake uses the SRCREV to
make sure that the upstream SCM repository is properly fetched.

>      SRCREV_meta_pn-linux-yocto_mymachine ?= \
>         "d05450e4aef02c1b7137398ab3a9f8f96da74f52"

This is the meta branch, which in current repositories is literally
called "meta".

>
>
>
>
>
>
> 6.  To me, if you are working with Edison and a particular BSP, then these 2
>
> commit strings should be constant forever, right?
>
>
> Yes, for the official / known BSP. If you do local work, you can of
> course have your
> own tree and advance both.
>
> Cheers,
>
> Bruce
>
>
> Thanks for taking the time to help me with this confusion.

I think we are getting there ! :)

Bruce

>
> Jim A
>
>
>
>
> _______________________________________________
>
> yocto mailing list
>
> yocto at yoctoproject.org
>
> https://lists.yoctoproject.org/listinfo/yocto
>
>
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"
>
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"