[yocto] BB_NO_NETWORK and own-mirrors not working with meta-systemd

[Evade Flow]

> You should not need to be specifying the revision within SRC_URI as you are
> doing, however, it is correct that you must specify the revision in
> SRCREV...

This doesn't appear to be done in a couple of the Yocto recipes:

  - meta/recipes-devtools/btrfs-tools/btrfs-tools_git.bb
  - meta/recipes-devtools/mtd/mtd-utils_1.4.9.bb

SRCREV is not set in either of these, but 'tag=' is supplied as part of
SRC_URI, i.e.:


  SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git;protocol=git;tag=fdb6c0402337d9607c7a39155088eaf033742752;branch=master"


I'm not sure what to make of that, but... I'll modify my Wiki entry to say
that SRCREV should be set (instead of a SRC_URI with 'tag=').



On Thu, Sep 20, 2012 at 5:41 PM, Paul Eggleton
<paul.eggleton at linux.intel.com> wrote:
> On Thursday 20 September 2012 16:08:41 Evade Flow wrote:
>> To bring this full circle... if you want to build behind a restrictive
>> firewall using pre-mirrored sources and BB_NO_NETWORK, be aware that
>> recipes which:
>>
>>   1. Specify a git repo as the source, and,
>>
>>   2. Specify the revision to be built using a tag name
>>
>>
>> will cause your build to abort when bitbake tries to run 'git ls-remote'
>> to resolve the tag name.  So don't specify SRC_URI like this:
>>
>>
>>   SRC_URI =
>> "git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git;tag=v
>> ${PV}"
>>
>> Instead, use:
>>
>>   SRC_URI =
>> "git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git;tag=8
>> 885ced062131214448fae056ef453f094303805;branch=master"
>>
>>
>> I added a note about this to the Wiki:
>>
>>   -
>> http://wiki.yoctoproject.org/wiki/How_do_I#Non-networked_Builds_and_Cached_
>> Git_Respositories
>>
>> I'm still new to Yocto, so someone please chime in if any of this
>> information is incorrect...
>
> You should not need to be specifying the revision within SRC_URI as you are
> doing, however, it is correct that you must specify the revision in SRCREV and
> that revision must be the full SHA1 hash and not just a tag or branch name.
> The reason for this is that tags are not fixed and could change, therefore if
> one is used we must query the server and resolve it to the current SHA1 hash
> every time the recipe is parsed.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre