On Sat, Aug 18, 2012 at 8:07 AM, Richard Purdie <[email protected]> wrote: > On Wed, 2012-08-15 at 16:06 -0400, Bruce Ashfield wrote: >> The kernel branch is no longer required by the yocto-kern-tools >> to locate BSP feature descriptions (it is the MACHINE:KTYPE >> descriptor), so we no longer require that the BSP branch be >> explicitly set. >> >> If a kernel branch is explicitly set, it is now used to trigger >> a checks to ensure that the branch really is being built. >> Otherwise the branch that the machine description creates will >> be built (just as it always was). >> >> This further simplies the use and configuration of a linux-yocto >> based kernel recipe. > > [...] > >> >> - # We have SRCREVs and we have branches so validation can continue! >> - current=`git branch |grep \*|sed 's/^\* //'` >> - if [ -n "$target_branch_head" ] && [ "$branch_head" != >> "$target_branch_head" ] && >> - [ "$target_branch_head" != "AUTOINC" ]; then >> - ref=`git show ${target_branch_head} 2>&1 | head -n1 || true` >> - if [ "$ref" = "fatal: bad object ${target_meta_head}" ]; then >> - echo "ERROR ${target_branch_head} is not a valid >> commit ID." >> - echo "The kernel source tree may be out of sync" >> - exit 1 >> - else >> - echo "Forcing branch $current to ${target_branch_head}" >> - git branch -m $current $current-orig >> - git checkout -b $current ${target_branch_head} >> - fi >> + containing_branches=`git branch --contains $target_branch_head | sed >> 's/^..//'` >> + if [ -z "$containing_branches" ]; then >> + echo "ERROR: SRCREV was set to \"$target_branch_head\", but no >> branches" >> + echo " contain this commit" >> + exit 1 >> + fi >> + ref=`git show ${target_branch_head} 2>&1 | head -n1 || true` >> + if [ "$ref" = "fatal: bad object ${target_meta_head}" ]; then >> + echo "ERROR ${target_branch_head} is not a valid commit ID." >> + echo "The kernel source tree may be out of sync" >> + exit 1 >> fi > > There is a bit of uncertainty flying around at the moment about why > these changes are failing on the autobuilder. For example: > > http://autobuilder.yoctoproject.org:8010/builders/nightly-mips/builds/560/steps/shell_138/logs/stdio > > Log data follows: > | DEBUG: Executing shell function do_validate_branches > | ERROR: SRCREV was set to "1c17c082b6ee565acc176cde5be835ac4269817b", but no > branches > | contain this commit > | ERROR: Function failed: do_validate_branches > > It looks like: > > http://git.yoctoproject.org/cgit.cgi/poky/commit/bitbake/lib/bb/fetch2/git.py?id=64662290d3e7deb0b6093b3959c3f3eddb873893 > > doesn't totally fix the problem. It allows the correct revisions to be > found and sets alternatives correctly but imports the wrong branch > config.
bugger. eh. But that's what I saw on the autobuilder as well. There are two repos, one is being updated, another isn't and the older/non updated one isn't being updated. But what's causing the inconsistency in the .git and no ".git" repos ? i.e aren't all the SRC_URIs now the same ? So why would one be fetched into in the downloads, and the other used for the build ? > > I don't really want to have to require a patched git binary so we may > end up having to rebuild the branch structure manually. Where would we have to do the branch rebuild ? From what I saw, in the broken repo, the blobs aren't even present .. so even if you know the branch names, you can't set the SRCREV and just dump it in the branch ref (which I've tried in the past, and it just breaks in equally impressive ways as). > > I guess the older code cared less about the branch name and more about > the revisions being present. And the old code was wrong .. or at least not very good. It misses scenarios where new BSPs are created, or other branches selected to be built by the board descriptions. Human's working on a kernel, work on branches, not git hashes and floating branches .. so this actually allows a BSP developer to control the content, and have the build system build what he wants. I can say is that this works fine here, has been working for over two months within Wind River and never a failure seen, but the fetch infrastructure is configured differently here. We can skip the changes for 1.3, but they are a big step forward in the tools and flexibility for working with the tree .. which was one of the macro goals that I for 1.3. Cheers, Bruce > > Cheers, > > Richard > > > > > > > _______________________________________________ > Openembedded-core mailing list > [email protected] > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
