[OE-core] Linux-yocto 3.0 crashes at do_patch...

[Andrei Gherzan]

Even after using your workaround i can still reproduce this issue. Yocto
linux still fails.

| ERROR. Could not find an excutable target for yocto/standard/base
| ERROR. Could not locate meta series for yocto/standard/beagleboard
| ERROR. Could not modify yocto/standard/base
NOTE: package
linux-yocto-3.0.24+git1+34e0d2b4b4e9778b31f9ea99ca43f0dc71a7ee23_1+6b4bf6173b0bd2d1619a8218bac66ebc4681dd35-r4:
task do_patch: Failed
ERROR: Task 3 (/media/HDD/yocto/poky/meta/recipes-kernel/linux/
linux-yocto_3.0.bb, do_patch) failed with exit code '1'

On Thu, May 17, 2012 at 11:48 PM, Flanagan, Elizabeth <
elizabeth.flanagan at intel.com> wrote:

> On Thu, May 17, 2012 at 7:59 AM, Andrei Gherzan <andrei at gherzan.ro> wrote:
> > Today i just gave another try.... same result.
>
> Responding here as well as the yocto list:
>
> A few people have been having this issue and after some discussion we
> think we have a root cause. Let me first explain what happened.
>
> The autobuilder infrastructure shares a common DL_DIR in order to
> optimize the builds and provide the source mirror. This DL_DIR is
> rsynced to the publicaly available source mirror on a regular basis.
> During our infrastructure upgrade the autobuilder attempted to pull
> the tar archive for linux-yocto-3.0
> (
> http://downloads.yoctoproject.org/mirror/sources/git2_git.yoctoproject.org.linux-yocto-3.0.tar.gz
> )
> but due to network issues related to our recent infrastructure upgrade
> the file ended up as a 0 byte file. This file was rsynced the the
> source mirror. A few days ago this was mentioned as an issue. Michael
> Halstead corrected the network issue and I manually removed the file.
> The autobuilder repulled the archive correctly and repopulated the
> source mirror with it.
>
> Things should have been ok at this point. However, we were still
> getting reports of people sporadically running into a 0 byte file. Not
> all the time, but some of the time. Michael Halstead and I just tailed
> out the apache logs with Tom Zanussi wgetting the problematic file,
> watching for failures. No failures were seen in the error logs however
> Tom was still getting sporadic 0 byte files. Which means that his
> request wasn't even hitting the server. I was not able to replicate
> this. The only difference we could see is that I generally do not go
> through a proxy whereas Tom was.
>
> Our theory at this point is that all of the people who are hitting
> this issue are going through a proxy and that their proxy setup has
> cached that 0 byte file and refuses to regenerate it. There isn't a
> lot we can do from our end about that other than suggest the following
> work around. If you run into odd fetch issues with *just* the
> linux-yocto-3.0 tar archive, clear out your DL_DIR of
> git2_git.yoctoproject.org.linux-yocto-3.0.tar.gz and set the
> following:
>
> PREMIRRORS ?= "\
> bzr://.*/.*   http://autobuilder.yoctoproject.org/sources/ \n \
> cvs://.*/.*   http://autobuilder.yoctoproject.org/sources/ \n \
> git://.*/.*   http://autobuilder.yoctoproject.org/sources/ \n \
> hg://.*/.*    http://autobuilder.yoctoproject.org/sources/ \n \
> osc://.*/.*   http://autobuilder.yoctoproject.org/sources/ \n \
> p4://.*/.*    http://autobuilder.yoctoproject.org/sources/ \n \
> svk://.*/.*   http://autobuilder.yoctoproject.org/sources/ \n \
> svn://.*/.*   http://autobuilder.yoctoproject.org/sources/ \n"
>
> MIRRORS =+ "\
> ftp://.*/.*      http://autobuilder.yoctoproject.org/sources/ \n \
> http://.*/.*     http://autobuilder.yoctoproject.org/sources/ \n \
> https://.*/.*    http://autobuilder.yoctoproject.org/sources/ \n"
>
> This will force the fetch to go to the autobuilder host of sources and
> should work around any proxy caching issues. Then call your local IT
> folks and ask them to clear out your proxy cache. If you run into any
> fetch issues not related to this file, please let me know.
>
> -b
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20120522/1f809577/attachment-0002.html>