From: Stephan Hoffmann <sho@relinux.de>
To: buildroot@busybox.net
Subject: [Buildroot] Problem using Linux kernel archive from Gitorious
Date: Thu, 17 Jan 2013 16:17:38 +0100 [thread overview]
Message-ID: <50F81612.5080404@relinux.de> (raw)
In-Reply-To: <20130117160133.61661524@skate>
Am 17.01.2013 16:01, schrieb Thomas Petazzoni:
> Dear Aras Vaichas,
>
> On Thu, 17 Jan 2013 14:47:47 +0000, Aras Vaichas wrote:
>
>> I am configuring Buildroot to use an OMAP-L138/DaVinci CPU. I'd like
>> to use the Linux kernel version from
>> http://gitorious.org/linux-davinci/linux-davinci/trees/v3.7-davinci1
>> which is a specific tag in the git repository.
>>
>> In Buildroot I set:
>> BR2_LINUX_KERNEL_CUSTOM_TARBALL=y
>> BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION=http://gitorious.org/linux-davinci/linux-davinci/archive-tarball/v3.7-davinci1
>>
>> The file that is returned has the name "v3.7-davinci1", and it is a
>> "gzip compressed data, from Unix" according to file.
>>
>> Gitorious calls it a "tarball" but it's obviously not a tarball.
> It most likely is. When a tarball is gzipped compressed, "file" only
> reports it as a gzipped compressed file, it doesn't know there is a
> tarball inside.
>
>> Unfortunately Buildroot fails because, understandably, the file isn't
>> a tar archive.
>>
>>>>> linux custom Extracting
>> /opt/br/dl/v3.7-davinci1 | tar --strip-components=1 -C
>> /opt/br/output/build/linux-custom -xf -
>> /bin/bash: /opt/br/dl/v3.7-davinci1: Permission denied
>> tar: This does not look like a tar archive
>> tar: Exiting with failure status due to previous errors
>>
>> Should I add an option to Buildroot to handle gzipped files? Or is
>> there a better way?
> The problem here is that since the filename doesn't end with .tar.gz,
> Buildroot doesn't know which extraction method to apply, and therefore
> doesn't apply any, which leads Buildroot to try to execute your tarball.
>
> Hum, I am not sure how to handle that. Should we try to extract simply
> with tar something that does not have an extension?
>
> Github sends a correct filename in the Content-Disposition header of
> the HTTP reply, and wget --content-disposition is supposed to name the
> output file according to this filename given in the HTTP reply, but it
> doesn't work for me... and anyway, Buildroot would have no way to know
> what is the new name of the file.
>
> I don't have a lot of ideas for now, unfortunately :-(
Hi Thomas,
what about using file instead of decoding the extension? If file says
"gzipped", then gunzip it and use file again to find out that it's tar?
This could be done until something useful comes out or, if not, a
descriptive error message could be generated.
Just my 2 cents
Stephan
>
> Thomas
--
reLinux - Stephan Hoffmann
Am Schmidtgrund 124 50765 K?ln
Tel. +49.221.95595-19 Fax: -64
www.reLinux.de sho at reLinux.de
next prev parent reply other threads:[~2013-01-17 15:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-17 14:47 [Buildroot] Problem using Linux kernel archive from Gitorious Aras Vaichas
2013-01-17 15:01 ` Thomas Petazzoni
2013-01-17 15:17 ` Stephan Hoffmann [this message]
2013-01-17 15:35 ` Stefan Fröberg
2013-01-19 13:20 ` Arnout Vandecappelle
2013-01-21 11:30 ` Aras Vaichas
2013-01-24 6:32 ` Arnout Vandecappelle
2013-01-24 13:10 ` Peter Korsgaard
2013-01-25 11:53 ` Aras Vaichas
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=50F81612.5080404@relinux.de \
--to=sho@relinux.de \
--cc=buildroot@busybox.net \
/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