[OE-core] uninative binary?

[Christopher Larson]

On Mon, Nov 7, 2016 at 11:41 PM, Gary Thomas <gary at mlbassoc.com> wrote:

> On 2016-11-04 11:03, Richard Purdie wrote:
>
>> On Fri, 2016-11-04 at 08:16 +0100, Gary Thomas wrote:
>>
>>> Some of my customers need to be able to build without any
>>> network connectivity, so I normally use BB_NO_NETWORK="1"
>>>
>>> Is there a way to add the uninative "binary shim" to my
>>> download mirror?  Given that the path includes a hash as
>>> a directory, it's not clear to me how to put it into my
>>> mirror.
>>>
>>> Thanks for any ideas
>>>
>>
>> Set UNINATIVE_URL to point at your mirror?
>>
>> If the file already exists in DL_DIR, it will be used without touching
>> the network.
>>
>
> Thanks, that worked.  I keep a link to my mirror in my meta tree,
> so I added these lines to my ${DISTRO}.conf:
>   UNINATIVE_URL ?= "file://${COREBASE}/sources/uninative/1.4/"
>   require conf/distro/include/yocto-uninative.inc
>   INHERIT += "uninative"
> When I ran a build, this got sucked into my ${DL_DIR} as
>   $ ls -lR downloads/uninative/
>   downloads/uninative/:
>   total 4
>   drwxrwxr-x 2 gthomas gthomas 4096 Nov  7 13:02
> 101ff8f2580c193488db9e76f9646fb6ed38b65fb76f403acb0e2178ce7127ca
>
>   downloads/uninative/101ff8f2580c193488db9e76f9646fb6ed38b65f
> b76f403acb0e2178ce7127ca:
>   total 4
>   lrwxrwxrwx 1 gthomas gthomas 76 Nov  7 13:02
> x86_64-nativesdk-libc.tar.bz2 -> /local/poky-cutting-edge/sourc
> es/uninative/1.4/x86_64-nativesdk-libc.tar.bz2


It seems the uninative fetch does use mirrors, as well, from what I’ve
seen. At least, premirrors. I see a bunch of irritating fetch failure
messages from each of my premirrors when attempting to get uninative in
certain builds.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20161108/779228a5/attachment-0002.html>