[linux-yocto] kernel-yocto: validate_branches questions

Tue Feb 18 07:15:43 PST 2014

On 14-02-17 06:52 PM, Moore, Tysen wrote:
> I have some questions regarding creating a recipe for a kernel build.  
> Specifically I am having troubles with the validate_branches 
> (kernel-yocto.bbclass).  I have the following set:
> KBRANCH = "axsb/axsb_dra7xx-evm_6_03_00_01.XSE"
> SRCREV_machine = "717bdd79798d9fa41bc8bd2d089b17ebb52819cd"
> SRCREV = "717bdd79798d9fa41bc8bd2d089b17ebb52819cd"
> KMETA is not set.

Sorry for the slower than normal reply, yesterday was a holiday here.

Quick question, is this on master ? I apologize if this is covered, but
my scan missed it!

>
> The output for the verify_branches indicates that two different 
> branches have the same commit (717bdd797)--my KBRANCH and another 
> (fred/xsrapid-demo-glsdk-6.0.3.0).  However only the one I specified 
> in KBRANCH contains the defconfig that I need, the other does 
> not--neither does master.  The other potential issue is that the other 
> branch head is not 717bdd797.  When looking at the code I can see the 
> file exists from the normal fetch and unpack.  It is when the 
> validate_branches does the "git checkout -q master" that it checks out 
> master and the file is obviously gone.  The next for loop checks for 
> the head commit of the braches containing my commit and if not head it 
> switches to them.  This is the part that is especially troublesome.  
> It switches to the wrong branch and then since I have no KMETA 
> configured exists out.  My questions are:
> 1. Why does it not just switch to the KBRANCH I specified originally?  
> Isn't that the point of KBRANCH to ensure the correct branch is used.

For the most part, the point of KBRANCH is to keep the fetcher happy. It
needs a branch and SRCREV to ensure that what you want to build is in
the repository. Note that do_validate_branches pre-dates the fetcher changes
that help enforce what it was imposing on the kernel tree, so I have a 
mostly
re-written version of the routine that will be submitted to master in 
the not
to distant future.

As for what you build, KBRANCH is a hint. What you actually build is 
described
by the BSP .scc files (auto-generated or not). Typically the two sources of
input agree, if they don't, a warning is generated.

As the kernel patches, configuration and features are processed, the tree is
manipulated, that manipulation can involve git merges, or other operations
that require branch changes, so immediately checking it out isn't done 
.. since
the branches can change before landing on what is built.

do_validate_branches has had a few revisions over time to deal with 
different
workflows and bugs, so what you see represents fixes for various issues
that may arise .. which of course means, that I modify it very carefully to
not cause regressions :)

So what happens in that loop you are having trouble with, is that the SRCREV
as specified represents the head commit of what should be built .. or 
patched ..
and since the tree can be manipulated as part of the build process, 
do_validate_branches
looks for that commit in the tree, and resets any branches that contain the
commit .. to that commit, so if any one of those branches is used to 
build, you
will start from the SRCREV as specific in the recipe, that's your 
consistent baseline.

> 2. What is the difference between SRCREV and SRCREV_machine?

Just the standard bitbake variable overrides. SRCREV_machine is the
machine specific override for the SRCREV.

> 3. If I comment out the KMETA check resolves the problem.  The code 
> that follows reverts back to the KBRANCH as I would hope. Is this the 
> root of my problem?  If so, what is the use for KMETA? (Can't find 
> much of anything online) In much of the bb code it can be unset and is 
> assumed "meta".  While, this routine may seem to expect something.

Which kmeta check ? If you don't actually have a meta branch in your
kernel tree, and you've left it empty the validation should return early
and not process anything.

KMETA is for trees that have kernel configuration and BSP descriptions
stored within the tree itself .. that's the meta data, and it is contained
in the branch pointed to by KMETA.

>
> Any help or insight would be MUCH appreciated.

We may have a bug .. so let's see what we can figure out :)

Bruce

>
> Tysen
>
> LOG BELOW: (with my debug output: "FILE HERE..." or "FILE GONE..." to 
> track the file I need)
>
> + do_validate_branches
>
> + cd 
> /home/tmoore/work/axsb/build/tmp-external-linaro-toolchain/work/xse_axsb-oe-linux-gnueabi/linux-glsdk/3.8.13-xse-r6.2+r717bdd79798d9fa41bc8bd2d089b17ebb52819cd/git
> + export KMETA=
> + KMETA=
> + machine_branch=axsb/axsb_dra7xx-evm_6_03_00_01.XSE
> + '[' '!' -f 
> /home/tmoore/work/axsb/build/tmp-external-linaro-toolchain/work/xse_axsb-oe-linux-gnueabi/linux-glsdk/3.8.13-xse-r6.2+r717bdd79798d9fa41bc8bd2d089b17ebb52819cd/git/arch/arm/configs/axsb_defconfig 
> ']'
> + echo 'FILE HERE: 1'
> FILE HERE: 1
> + set +e
> + '[' 717bdd79798d9fa41bc8bd2d089b17ebb52819cd = AUTOINC ']'
> + '[' 717bdd79798d9fa41bc8bd2d089b17ebb52819cd = INVALID ']'
> + '[' 717bdd79798d9fa41bc8bd2d089b17ebb52819cd = '' ']'
> + git show-ref --quiet --verify -- 
> refs/heads/axsb/axsb_dra7xx-evm_6_03_00_01.XSE
>
> + '[' 0 -eq 1 ']'
> + '[' -z 717bdd79798d9fa41bc8bd2d089b17ebb52819cd ']'
> + target_branch_head=717bdd79798d9fa41bc8bd2d089b17ebb52819cd
>
> + '[' 717bdd79798d9fa41bc8bd2d089b17ebb52819cd = AUTOINC ']'
>
> ++ git show 717bdd79798d9fa41bc8bd2d089b17ebb52819cd
>
> ++ head -n1
>
> + ref='commit 717bdd79798d9fa41bc8bd2d089b17ebb52819cd'
> + '[' 'commit 717bdd79798d9fa41bc8bd2d089b17ebb52819cd' = 'fatal: bad 
> object ' ']'
>
> ++ git branch --contains 717bdd79798d9fa41bc8bd2d089b17ebb52819cd
>
> ++ sed 's/^..//'
>
> + containing_branches='axsb/axsb_dra7xx-evm_6_03_00_01.XSE
> fred/xsrapid-demo-glsdk-6.0.3.0'
> + '[' -z 'axsb/axsb_dra7xx-evm_6_03_00_01.XSE
> fred/xsrapid-demo-glsdk-6.0.3.0' ']'
>
> + '[' '!' -f 
> /home/tmoore/work/axsb/build/tmp-external-linaro-toolchain/work/xse_axsb-oe-linux-gnueabi/linux-glsdk/3.8.13-xse-r6.2+r717bdd79798d9fa41bc8bd2d089b17ebb52819cd/git/arch/arm/configs/axsb_defconfig 
> ']'
> + echo 'FILE HERE: 2'
> FILE HERE: 2
> + git checkout -q master
>
> + '[' '!' -f 
> /home/tmoore/work/axsb/build/tmp-external-linaro-toolchain/work/xse_axsb-oe-linux-gnueabi/linux-glsdk/3.8.13-xse-r6.2+r717bdd79798d9fa41bc8bd2d089b17ebb52819cd/git/arch/arm/configs/axsb_defconfig 
> ']'
> + echo 'FILE GONE: 3'
> FILE GONE: 3
> + for b in '$containing_branches'
>
> ++ git show-ref -s --heads axsb/axsb_dra7xx-evm_6_03_00_01.XSE
>
> + branch_head=717bdd79798d9fa41bc8bd2d089b17ebb52819cd
> + '[' 717bdd79798d9fa41bc8bd2d089b17ebb52819cd '!=' 
> 717bdd79798d9fa41bc8bd2d089b17ebb52819cd ']'
>
> + '[' '!' -f 
> /home/tmoore/work/axsb/build/tmp-external-linaro-toolchain/work/xse_axsb-oe-linux-gnueabi/linux-glsdk/3.8.13-xse-r6.2+r717bdd79798d9fa41bc8bd2d089b17ebb52819cd/git/arch/arm/configs/axsb_defconfig 
> ']'
> + echo 'FILE GONE: 4'
> FILE GONE: 4
> + for b in '$containing_branches'
>
> ++ git show-ref -s --heads fred/xsrapid-demo-glsdk-6.0.3.0
>
> + branch_head=c826758fbc186d8b93881fda84ef3d341c3f401b
> + '[' c826758fbc186d8b93881fda84ef3d341c3f401b '!=' 
> 717bdd79798d9fa41bc8bd2d089b17ebb52819cd ']'
>
> + echo '[INFO] Setting branch fred/xsrapid-demo-glsdk-6.0.3.0 to 
> 717bdd79798d9fa41bc8bd2d089b17ebb52819cd'
> [INFO] Setting branch fred/xsrapid-demo-glsdk-6.0.3.0 to 
> 717bdd79798d9fa41bc8bd2d089b17ebb52819cd
> + '[' fred/xsrapid-demo-glsdk-6.0.3.0 = master ']'
> + git branch -D fred/xsrapid-demo-glsdk-6.0.3.0
>
> + git branch fred/xsrapid-demo-glsdk-6.0.3.0 
> 717bdd79798d9fa41bc8bd2d089b17ebb52819cd
>
> + '[' '!' -f 
> /home/tmoore/work/axsb/build/tmp-external-linaro-toolchain/work/xse_axsb-oe-linux-gnueabi/linux-glsdk/3.8.13-xse-r6.2+r717bdd79798d9fa41bc8bd2d089b17ebb52819cd/git/arch/arm/configs/axsb_defconfig 
> ']'
> + echo 'FILE GONE: 4'
> FILE GONE: 4
> + '[' '!' -f 
> /home/tmoore/work/axsb/build/tmp-external-linaro-toolchain/work/xse_axsb-oe-linux-gnueabi/linux-glsdk/3.8.13-xse-r6.2+r717bdd79798d9fa41bc8bd2d089b17ebb52819cd/git/arch/arm/configs/axsb_defconfig 
> ']'
>
> + echo 'FILE GONE: 5'
> FILE GONE: 5
>
> ++ git show-ref -s --heads
>
> + meta_head='cc6f2e3c9b2eb0ef9c39c5a68ffee2a82598a4a9
> fe728c6a3f25f0a7587bae9b65dea10554e102fc
> fa4fb0e8f4dcd5db46742b83aed2ee7815d5ec6f
> f390b6b55f51acbdb4d5b0b078c6f15456a2039a
> da0eb1c4b3c34efd972cc3e91956ba94fcaf9d11
> ec83154ff7d40c1aedee037774c1eae1af9b5272
> 191aac72ee0ee05db715001c8bb0591d23efad9a
> c8e36139549ca011e06b1b8a3b4c654642512d93
> b5b08324e97f1c1e1ee9753d96281db9124d3f0e
> 717bdd79798d9fa41bc8bd2d089b17ebb52819cd
> 44b6f4e4dd28eb685b9e749077b36758724f2b24
> 670455b7933db0657bb967035baee287b405b2d2
> d9c78bd70922a139f6c7058fbe8f671d20f34894
> 0eff28a072da8a576ca74a7abd029d9ee46f8ca1
> 02e38cca0c29dce3a26faab3a73be0e6162d6c84
> 182410a5afefb19f6ed39fcf70a0909279e7a9cd
> b1dad199b221c61968ae5f67d9f8bd421f7dca82
> 47c620e3d0cca8fae09c7a4479c1176dc3617275
> 108f5f5a2a1c84a5bd5a7644fd07245b57096641
> 40278d335876b34992a0d7b4f9eb07f836444edf
> 01d6327f543c9c63bb1f5f91ba86d63c89570edb
> b3e34fd37ac6b8bad95fa1c49d434e456c97e9e8
> 717bdd79798d9fa41bc8bd2d089b17ebb52819cd
> 930c92b97941b38279afa039e6f1476f84a1975c
> b2466bf8dd75f027b2cb1d7ccf8c8d98f8dd49b0
> 02e88a40ed1d986556709f3d6169b3e4c9db4222
> 56921b5630e2057f6ed36ebd4a530e4df31762b1
> 93adb84960f8ec3619d2303ba8579048f5c9efa4
> c12fe703345ebe74f1eaa67f43255ca1cd3e486c
> b1c76e8f3b4a8e45920b9b9c6282ab8ab420988b
> 5d1cca3f8824ab1dcffa276a4de1c9da014d47bc
> ef5ec564ed80b69711a0544965a9c533d2e65814
> 02e8b25c26961d331b4e3a0b301978f8f659219a
> 564e2296299f7d8dd2704694ed65efad0980307d
> 2f6233aef7bc00c04c1be07050cdb9623f11bce2
> 48ddbf278cdcc49955237d324702c34cbb69149b
> dbf932a9b316d5b29b3e220e5a30e7a165ad2992
> dbf932a9b316d5b29b3e220e5a30e7a165ad2992
> 401b1e78120fca344bf161a82017e1b9e164df23
> 9346b7f8a29b0886dc838bee3d0930bcdbfbd7e4
> 2699a2192207494da6d1b344445ccbe33949489a
> b67697f031cefe75f2e402fa907dedaad75619c3
> d973103bcd57e4cf788ff3389c1f9b4243b5374a
> d3d9e1ad087cf6f618fa94af9042790643d236b0
> cd44a3dc37bba7986f9d39d66e666a3b68583588
> 7609125e6b3f8e964dff0518992d1b57198e866f
> 89927f5573872cada07d07c714e24a71ed6c29c3
> e1a352a9f297fc5f17b5dd6f6b3e87bbce3663e6
> a45a092c3abe23e4deec03e129a0eef04c6ed41e
> cc8a7df79eee5e837eab0f0b10f5bb7f14548c1e
> 6e434412aecdf304915efac90ed6e7bb6af5d800
> c5f08f6d2fd8a558bdf0f7b801fb014cfd97dcb8
> 6e434412aecdf304915efac90ed6e7bb6af5d800'
> + target_meta_head=
> + git show-ref --quiet --verify -- refs/heads/
>
> + '[' 1 -eq 1 ']'
> + return
>
>
>
> XSe Logo
>
> *XS Embedded LLC*
> 29065 Cabot Drive, Suite 200
> Novi, MI 48377
> USA
>
> Phone 	+1 (248) 209 - 6613
> Fax 	+1 (248) 281 - 7020
>
>
> www.xs-embedded.com <http://www.xs-embedded.com>
> Tysen.Moore at xs-embedded.com <mailto:Tysen.Moore at xs-embedded.com>
>
> *:::::::::: based.on.visions ::::::::::*
>
> XS Embedded LLC
> Managing Director: Joachim Kobinger
>
> Confidentiality Notice: This e-mail message, including any 
> attachments, is for the sole use of the intended recipient(s) and may 
> contain confidential and privileged information. Any unauthorized 
> review, use, disclosure or distribution is prohibited. If you are not 
> the intended recipient, please contact the sender by return e-mail and 
> destroy all copies of the original message.
>
>
>
>
> _______________________________________________
> linux-yocto mailing list
> linux-yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/linux-yocto

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/linux-yocto/attachments/20140218/ef1e3c9f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 781 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/linux-yocto/attachments/20140218/ef1e3c9f/attachment.gif>