All of lore.kernel.org
 help / color / mirror / Atom feed
From: Darren Hart <darren.hart@intel.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: yocto@yoctoproject.org, Saul Wold <saul.wold@intel.com>
Subject: Re: Details on Bug #963 kernel tarball corruption.
Date: Thu, 07 Jul 2011 16:57:54 -0700	[thread overview]
Message-ID: <4E164802.4000206@intel.com> (raw)
In-Reply-To: <1310073373.20015.847.camel@rex>

On 07/07/2011 02:16 PM, Richard Purdie wrote:
> On Thu, 2011-07-07 at 13:34 -0700, Flanagan, Elizabeth wrote:
>> I wanted to ping the list on this bug as I've drilled down into it and
>> I see what's going on. These are the steps to reproduce it and I have
>> some questions at the end....
>>
>> The issue: The autobuilder has been serving up bad kernel source
>> tarballs. This is not an autobuilder issue. I've narrowed this down to
>> being an issue with do_fetch and do_unpack....
>>
>> First, I created a local linux-yocto repo and modified
>> meta/recipes-kernel/linux/linux-yocto_2.6.37.bb to point to it:
>>
>> SRCREV_machine = ${AUTOREV}
>> SRCREV_meta = ${AUTOREV}
>>
>> SRC_URI = "git:///srv/build/build/repo/git.pokylinux.org.linux-yocto-2.6.37;protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
>>
>> I do bitbake virtual/kernel -c kernel_checkout -f and the repo is
>> fetched into my DL_DIR, unpacked into
>> tmp/work/qemux86-poky-linux/linux-yocto-2.6.37....r20/git and then
>> do_kernel_checkout runs. At this point, everything is correct.
>>
>> At this point my local SRC_URI repo is:
>>
>> * master
>>   meta
>>   yocto/base
>>   yocto/eg20t
>>   yocto/emgd
>>   yocto/gma500
>> ....
>>
>> My clone in DL_DIR is the same.
>>
>> My clone in  tmp/work/qemux86-poky-linux/linux-yocto-2.6.37....r20/linux
>> looks like this:
>>
>>   master
>>   meta
>>   yocto/base
>>   yocto/eg20t
>>   yocto/emgd
>>   yocto/gma500
>>   ....
>>   remotes/origin/master
>>   remotes/origin/meta
>>   remotes/origin/yocto/base
>>   remotes/origin/yocto/eg20t
>>   remotes/origin/yocto/emgd
>>   remotes/origin/yocto/gma500
>>
>> With the local head branches and the remotes being the same.
>>
>> Now, on to where this gets ugly.
>>
>> I commit a new branch to my SRC_URI repo:
>>
>> My SRC_URI:
>>
>> BAD_BRANCH
>> master
>> meta
>> yocto/base
>> yocto/eg20t
>> yocto/emgd
>> yocto/gma500
>> ....
>>
>> I re-run fetch and my DL_DIR looks like this:
>>
>> * master
>>   meta
>>   yocto/base
>>   yocto/eg20t
>>   yocto/emgd
>>   yocto/gma500
>> ....
>>   remotes/origin/BAD_BRANCH
>>   remotes/origin/master
>>   remotes/origin/meta
>>   remotes/origin/yocto/base
>>   remotes/origin/yocto/eg20t
>>   remotes/origin/yocto/emgd
>>   remotes/origin/yocto/gma500
>>
>> Notice, the new BAD_BRANCH is now only in remotes. This *should* be
>> ok, since after we do_unpack we run do_kernel_checkout which should
>> copy the refs in remotes to heads
> 
> I think we hit game over at this point. BAD_BRANCH should be present and
> isn't :(.
> 
> I talked quickly with Beth over jabber. I think this is a fetcher bug
> and something like:
> 
> diff --git a/bitbake/lib/bb/fetch2/git.py b/bitbake/lib/bb/fetch2/git.py
> index f3bc793..7954f66 100644
> --- a/bitbake/lib/bb/fetch2/git.py
> +++ b/bitbake/lib/bb/fetch2/git.py
> @@ -170,7 +170,7 @@ class Git(FetchMethod):
>  
>          # If the repo still doesn't exist, fallback to cloning it
>          if not os.path.exists(ud.clonedir):
> -            clone_cmd = "%s clone --bare %s://%s%s%s %s" % \
> +            clone_cmd = "%s clone --bare --mirror %s://%s%s%s %s" % \


--mirror implies --bare, so:
-            clone_cmd = "%s clone --bare %s://%s%s%s %s" % \
+            clone_cmd = "%s clone --mirror %s://%s%s%s %s" % \

should be adequate.

--
Darren

>                    (ud.basecmd, ud.proto, username, ud.host, ud.path, ud.clonedir)
>              bb.fetch2.check_network_access(d, clone_cmd)
>              runfetchcmd(clone_cmd, d)
> @@ -188,7 +188,7 @@ class Git(FetchMethod):
>              except bb.fetch2.FetchError:
>                  logger.debug(1, "No Origin")
>              
> -            runfetchcmd("%s remote add origin %s://%s%s%s" % (ud.basecmd, ud.proto, username, ud.host, ud.path), d)
> +            runfetchcmd("%s remote add --mirror origin %s://%s%s%s" % (ud.basecmd, ud.proto, username, ud.host, ud.path), d)
>              fetch_cmd = "%s fetch --all -t" % ud.basecmd
>              bb.fetch2.check_network_access(d, fetch_cmd, ud.url)
>              runfetchcmd(fetch_cmd, d)
> 
> might just fix this (since it means a refspec is added to keep the
> remote and local heads in sync).
> 
> Cheers,
> 
> Richard
> 


-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


  reply	other threads:[~2011-07-07 23:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-07 20:34 Details on Bug #963 kernel tarball corruption Flanagan, Elizabeth
2011-07-07 20:42 ` Flanagan, Elizabeth
2011-07-07 21:16 ` Richard Purdie
2011-07-07 23:57   ` Darren Hart [this message]
2011-07-08  0:08     ` Richard Purdie
2011-07-07 21:51 ` Tom Zanussi
2011-07-07 22:31   ` Flanagan, Elizabeth
2011-07-07 22:46     ` Richard Purdie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E164802.4000206@intel.com \
    --to=darren.hart@intel.com \
    --cc=richard.purdie@linuxfoundation.org \
    --cc=saul.wold@intel.com \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.