[bitbake-devel] [**EXTERNAL**] Re: Sumo to Thud migration: Fetch failure from gitsm.py
da Silva Filho, Josias Inacio
jdasilva at ciena.com
Tue Dec 4 20:50:41 UTC 2018
Bingo! Indeed the module was added into .gitmodules but not added in the repo itself.
I will get someone to add the repo then I will re-test, but that looks to be the issue.
Thanks Mark!
-----Original Message-----
From: Mark Hatle <mark.hatle at windriver.com>
Sent: Monday, November 26, 2018 9:09 AM
To: da Silva Filho, Josias Inacio <jdasilva at ciena.com>; bitbake-devel at lists.openembedded.org
Subject: [**EXTERNAL**] Re: [bitbake-devel] Sumo to Thud migration: Fetch failure from gitsm.py
On 11/22/18 9:31 AM, da Silva Filho, Josias Inacio wrote:
> Hi folks,
>
>
>
> I'm working on migrating my environment from Sumo to Thud. After
> fixing a few quirks, it seems the fetch is failing for my foo.bb which uses gitsm.
>
>
>
> *.gitmodules content in foo repo:*
>
> [submodule "common-lib"]
>
> path = common-lib
>
> url = ssh://git@<url_to_common-lib>/common-lib.git
>
>
>
> *foo.bb:*
>
> SRC_URI="gitsm://git@b<url_to_foo>.git;protocol=ssh;branch=master"
>
> SRCREV="f55fae9dc9b476f8ed193f15e2d5cd6747777451"
>
>
>
> Digging inside gitsm.py it looks like module_hash is not being set
> correctly
> (empty) and that causes the issue:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/bitbake/lib/bb/fet
> ch2/gitsm.py#n87
>
>
>
> I added the following right after line 87, so I could dump the
> variables content. This is how I confirmed module_hash is empty:
>
> *raise bb.fetch2.FetchError('module: %s, submodules: %s, module_hash:
> %s,
> basecmd: %s, revisions: %s, paths: %s, clonedir: %s ' % ( module,
> submodules, module_hash, ud.basecmd, ud.revisions[name],
> paths[module], ud.clonedir))*
Run the cloning steps manually. And run the same git instructions as what the gitsm fetcher does to find the hash for the submodule.
git clone --bare <url> <destination>
cd <destination>
git show <commit>:.gitmodules
for each of the modules listed:
git ls-tree -z -d <commit> <module path>
It's the bit in the for loop that doesn't seem to be returning anything. The only time I've ever seen this not work is when a module is defined in the .gitmodules file, but was never actually added to the repository.
>
>
> And the output:
>
> ERROR: Fetcher failure: module: common-lib, submodules:
> ['common-lib'],
> *module_hash*: , basecmd: git -c core.fsyncobjectfiles=0, revisions:
> f55fae9dc9b476f8ed193f15e2d5cd6747777451, paths: common-lib, clonedir:
> /localdata/yocto/downloads/git2/<foo's path>.git
git clone --bare ssh://git@b<url_to_foo>.git my_repo cd my_repo git show f55fae9dc9b476f8ed193f15e2d5cd6747777451:.gitmodules
for each of the modules listed: (focusing on common-lib)
git ls-tree -z -d f55fae9dc9b476f8ed193f15e2d5cd6747777451 common-lib
BTW my suggestion is to throw an exception or at least do a warning in the for loop if module_hash is empty... since this is clearly an invalid configuration.
(after the split line)
if not module_hash:
logger.warning("Submodule %s of %s does not appear to have a commit defined."
% ( ud.url, module ))
--Mark
> Any ideas why module_hash is not being set correctly?
>
>
>
>
>
More information about the bitbake-devel
mailing list