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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox