From: Gary Thomas <gary@mlbassoc.com>
To: Paul Eggleton <paul.eggleton@linux.intel.com>
Cc: openembedded-devel@lists.openembedded.org
Subject: Re: meta-browser
Date: Thu, 17 May 2012 09:19:48 -0600 [thread overview]
Message-ID: <4FB51714.8030201@mlbassoc.com> (raw)
In-Reply-To: <2161931.GEEF89rDH1@helios>
On 2012-05-17 09:04, Paul Eggleton wrote:
> On Thursday 17 May 2012 08:46:08 you wrote:
>> On 2012-05-17 08:37, Paul Eggleton wrote:
>>> On Thursday 17 May 2012 08:18:47 Gary Thomas wrote:
>>>> Trying the new layer, when I ran 'bitbake chromium -c fetch', I got this
>>>> error: Fetcher failure for URL:
>>>> 'http://commondatastorage.googleapis.com/chromium-browser-official/chromi
>>>> um
>>>> -19.0.1049.3.tar.bz2'. The fetch command returned success for url
>>>> http://commondatastorage.googleapis.com/chromium-browser-official/chromiu
>>>> m-
>>>> 19.0.1049.3.tar.bz2 but
>>>> /local/p60_poky/downloads/chromium-19.0.1049.3.tar.bz2 doesn't exist?!
>>>>
>>>> Looking at my tree, I found this:
>>>>
>>>> downloads/chromium-19.0.1049.3.tar.bz2?cms_redirect=yes&redirect_counter=
>>>> 1
>>>> which has MD5SUM that matches the recipe.
>>>>
>>>> Any ideas what might have gone wrong?
>>>
>>> If it really has "?cms_redirect=yes&redirect_counter=1" at the end of the
>>> filename that might have something to do with it...
>>
>> Of course, but that's a result of the fetcher code - the recipe does not
>> have such:
>> SRC_URI =
>> "http://commondatastorage.googleapis.com/chromium-browser-official/${P}.tar
>> .bz2"
>>
>> The fetch log is at http://www.mlbassoc.com/misc/chromium_fetch.log
>> My build host is Fedora 16 (i686)
>> My oe-core (poky/master) is rev 38da655788
>
> Out of curiosity I tried to download the file manually and got a 404, so I
> think there is a bigger issue with this recipe than fetcher behaviour...
Interesting because the fetcher did get the file for me, albeit with those
decorations, that has the correct MD5SUM
-rw-rw-r-- 1 gthomas gthomas 176721817 Feb 23 14:57 downloads/chromium-19.0.1049.3.tar.bz2
(I stripped the decorations manually)
It does look like there's a lot of redirecting going on which is causing the
wget behaviour:
$ wget http://commondatastorage.googleapis.com/chromium-browser-official/chromium-19.0.1049.3.tar.bz2
--2012-05-17 09:16:00-- http://commondatastorage.googleapis.com/chromium-browser-official/chromium-19.0.1049.3.tar.bz2
Resolving commondatastorage.googleapis.com... 74.125.225.76, 74.125.225.74, 74.125.225.75
Connecting to commondatastorage.googleapis.com|74.125.225.76|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://redirector-bigcache.googleapis.com/chromium-browser-official/chromium-19.0.1049.3.tar.bz2 [following]
--2012-05-17 09:16:01-- http://redirector-bigcache.googleapis.com/chromium-browser-official/chromium-19.0.1049.3.tar.bz2
Resolving redirector-bigcache.googleapis.com... 209.85.225.95
Connecting to redirector-bigcache.googleapis.com|209.85.225.95|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://o-o.preferred.atl14s01.v2.lscache4.c.bigcache.googleapis.com/chromium-browser-official/chromium-19.0.1049.3.tar.bz2?cms_redirect=yes [following]
--2012-05-17 09:16:02-- http://o-o.preferred.atl14s01.v2.lscache4.c.bigcache.googleapis.com/chromium-browser-official/chromium-19.0.1049.3.tar.bz2?cms_redirect=yes
Resolving o-o.preferred.atl14s01.v2.lscache4.c.bigcache.googleapis.com... 173.194.11.234
Connecting to o-o.preferred.atl14s01.v2.lscache4.c.bigcache.googleapis.com|173.194.11.234|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://v2.cache2.c.bigcache.googleapis.com/chromium-browser-official/chromium-19.0.1049.3.tar.bz2?cms_redirect=yes&redirect_counter=1 [following]
--2012-05-17 09:16:03-- http://v2.cache2.c.bigcache.googleapis.com/chromium-browser-official/chromium-19.0.1049.3.tar.bz2?cms_redirect=yes&redirect_counter=1
Resolving v2.cache2.c.bigcache.googleapis.com... 74.125.212.49
Connecting to v2.cache2.c.bigcache.googleapis.com|74.125.212.49|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 176721817 (169M) [application/x-bzip2]
Saving to: “chromium-19.0.1049.3.tar.bz2?cms_redirect=yes&redirect_counter=1”
...
I wonder if wget should be using the -O option to force the resulting filename?
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
next prev parent reply other threads:[~2012-05-17 15:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-17 14:18 meta-browser Gary Thomas
2012-05-17 14:37 ` meta-browser Paul Eggleton
2012-05-17 14:46 ` meta-browser Gary Thomas
2012-05-17 15:04 ` meta-browser Paul Eggleton
2012-05-17 15:19 ` Gary Thomas [this message]
2012-05-17 15:30 ` meta-browser Eric Bénard
2012-05-17 15:52 ` meta-browser Eric Bénard
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=4FB51714.8030201@mlbassoc.com \
--to=gary@mlbassoc.com \
--cc=openembedded-devel@lists.openembedded.org \
--cc=paul.eggleton@linux.intel.com \
/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.