Bug 14333 - submodule helper is not handled properly for devtool enabled workspace
Summary: submodule helper is not handled properly for devtool enabled workspace
Status: RESOLVED FIXED
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: devtools / tool chain (show other bugs)
Version: unspecified
Hardware: x86 Multiple
: Medium+ critical
Target Milestone: 3.3 M4
Assignee: Prabin CA
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2021-04-01 10:46 UTC by Prabin CA
Modified: 2021-05-25 01:32 UTC (History)
6 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: Don't know


Attachments
screen shot of bbappend resides in devtool workspace (41.11 KB, image/png)
2021-04-06 08:09 UTC, Prabin CA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Prabin CA 2021-04-01 10:46:59 UTC
Hi All,

I had updated oe-core to latest commit recently (as per today it is pointed to 2d903126e8bbece3a5171c3488c3deae1f0aa3ee). I have a weird observation with this recent commit, especially how submodule helper is used on workspace created by devtool. 

We have SRC_URI as follows on our edk2 recipes 

SRC_URI = "\
           gitsm://<url>;name=edk2;destsuffix=edk2;branchmaster \
           git://<url>;name=edk2-platforms;destsuffix=edk2/edk2-platforms;branch=master \
 "
our intention to fetch edk2-platform inside edk2 workspace. so that, we had set destsuffix as shown above. And we are getting required workspace (even with devtool also) successfully. 

Here edk2-platform is not a submodule of edk2. Once the workspace is created with "devtool modify <recipe_name>" command (edk2-platforms reside inside edk2 workspace),  "git submodule status" on edk2 workspace returns error as follows

"fatal: no submodule mapping found in .gitmodules for path 'edk2-platforms"

This error should be ignored since edk2-platforms is not a submodule of edk2. But Yocto build system does not have the intelligence to ignore this.

When we build this edk2 recipe with recent poky commits, we are getting following error

"CalledProcessError: Command '['git', 'submodule', 'status']' returned non-zero exit status 128" 

on bisecting over the oe-core commits, I had found commit: 42c86799ce265101b821030525ec568d34670430 causing the problem. I have reverted this commit as shown below and able to bypass above error.

diff --git a/meta/classes/externalsrc.bbclass b/meta/classes/externalsrc.bbclass
index 54cc7edbae..c7b2bf2f49 100644
--- a/meta/classes/externalsrc.bbclass
+++ b/meta/classes/externalsrc.bbclass
@@ -217,16 +217,14 @@ def srctree_hash_files(d, srcdir=None):
             env['GIT_INDEX_FILE'] = tmp_index.name
             subprocess.check_output(['git', 'add', '-A', '.'], cwd=s_dir, env=env)
             git_sha1 = subprocess.check_output(['git', 'write-tree'], cwd=s_dir, env=env).decode("utf-8")
-            submodule_helper = subprocess.check_output(['git', 'submodule', 'status'], cwd=s_dir, env=env).decode("utf-8")
+            submodule_helper = subprocess.check_output(['git', 'submodule--helper', 'list'], cwd=s_dir, env=env).decode("utf-8")
             for line in submodule_helper.splitlines():
-                module_relpath = line.split()[1]
-                if not module_relpath.split('/')[0] == '..':
-                    module_dir = os.path.join(s_dir, module_relpath)
-                    proc = subprocess.Popen(['git', 'add', '-A', '.'], cwd=module_dir, env=env, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
-                    proc.communicate()
-                    proc = subprocess.Popen(['git', 'write-tree'], cwd=module_dir, env=env, stdout=subprocess.PIPE, stderr=subprocess.DEVNULL)
-                    stdout, _ = proc.communicate()
-                    git_sha1 += stdout.decode("utf-8")
+                module_dir = os.path.join(s_dir, line.rsplit(maxsplit=1)[1])
+                proc = subprocess.Popen(['git', 'add', '-A', '.'], cwd=module_dir, env=env, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
+                proc.communicate()
+                proc = subprocess.Popen(['git', 'write-tree'], cwd=module_dir, env=env, stdout=subprocess.PIPE, stderr=subprocess.DEVNULL)
+                stdout, _ = proc.communicate()
+                git_sha1 += stdout.decode("utf-8")
             sha1 = hashlib.sha1(git_sha1.encode("utf-8")).hexdigest()
         with open(oe_hash_file, 'w') as fobj:
             fobj.write(sha1)

Either this commit (42c86799ce265101b821030525ec568d34670430) should be removed from oe-core or need a proper way of handling submodule helper on workspace created by devtool.

steps to reproduce the issues.

1. create a recipe with SRC_URI to checkout multiple workspace in recursive way (Refer SRC_URI I had mentioned above)
2. source enviroment
3. devtool modify <recipe_name>
4. cd workspace/sources/<recipe_name>/
5. git submodule status
   this shows error "fatal: no submodule mapping found in .gitmodules for path <pkg_name2>
6. cd -
4. bitbake <recipe_name>
   this gives error "CalledProcessError: Command '['git', 'submodule', 'status']' returned non-zero exit status 128"
Comment 1 Randy MacLeod 2021-04-01 14:47:52 UTC
Seems to be a duplicate. If not reopen as separate bug.

*** This bug has been marked as a duplicate of bug 14141 ***
Comment 2 Prabin CA 2021-04-01 14:53:40 UTC
This is not same issue as that of https://bugzilla.yoctoproject.org/show_bug.cgi?id=14141, this is the problem of oe-core how handle the return of git submodule status. I had mentioned a commit which cause the hazard in oe-core.
Comment 3 Randy MacLeod 2021-04-01 14:57:58 UTC
Are you able to send a patch?
Comment 4 Prabin CA 2021-04-01 15:02:38 UTC
patch to where ?
Comment 5 Randy MacLeod 2021-04-01 15:26:04 UTC
Hi Prabin,

Patches are reviewed on the oe-core email list so:
$ git send-email --to=openembedded-core@lists.openembedded.org --confirm=always -M -1
as described:
   https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded#Sending_patches

Let me know if you need help.
Comment 6 Prabin CA 2021-04-05 07:01:18 UTC
Hi,

I was getting below error

Send this email? ([y]es|[n]o|[q]uit|[a]ll): yes
STARTTLS failed! SSL wants a read first at /usr/lib/git-core/git-send-email line 1495.
Comment 7 Prabin CA 2021-04-05 15:47:00 UTC
Hi Douglas,

Do you have any comments on this, Do you haven any logic to resolve this issue. Since we are seeing this issue with "42c86799ce265101b821030525ec568d34670430".
Comment 8 Douglas Royds 2021-04-06 01:31:45 UTC
Hi Prabin

We don't use git:// or gitsm:// SRC_URI entries in externalsrc recipes. externalsrc recipes are those for which the source code is already available on your local HDD, you shouldn't be trying to fetch or unpack any git repository at all.

The externalsrc class deletes the fetch and unpack tasks for a recipe (unless you have "local" entries, ie. entries beginning with file:// etc).

The code you are referring to only gets run if you have both inherited externalsrc and set EXTERNALSRC to some fully-qualified path for your particular recipe (see the comment header in externalsrc.bbclass). Have you done this?

Additionally, the commit you are referring to (42c86799ce) doesn't exist on the master branch. Are you on the master branch? Did you mean this commit? https://git.openembedded.org/openembedded-core/commit/?id=4525310d49d115a37705f04ac5c03d639e5e8f8c 

Can you also post which git version you are running, please?
Comment 9 Prabin CA 2021-04-06 08:07:14 UTC
Hi Douglas,

Please find my inline replies.

Douglas: externalsrc recipes are those for which the source code is already available on your local HDD, you shouldn't be trying to fetch or unpack any git repository at all.

Prabin: We can see externalsrc have been inherited for devtool workspace, attached a screen shot (screen of auto created bb append file with devtool modify command), In this case its inheriting externalsrc automatically and setting EXTERNALSRC to devtool created workspace by automatically. 
Please not that, this workspace created by devtool is the out come of SRC_URI variable defined on our recipes (SRC_URI in bb/bbappend/inc file). 

Douglas: Additionally, the commit you are referring to (42c86799ce) doesn't exist on the master branch. Are you on the master branch? Did you mean this commit? https://git.openembedded.org/openembedded-core/commit/?id=4525310d49d115a37705f04ac5c03d639e5e8f8c 

Prabin: Yes, we can see this commit in oe-core master branch, and this commit is already merged to poky repo as well.
Comment 10 Prabin CA 2021-04-06 08:08:15 UTC
We need intelligent way of submodule handling in both local and devtool workspace in externalsrc class.
Comment 11 Prabin CA 2021-04-06 08:09:16 UTC
Created attachment 4784 [details]
screen shot of bbappend resides in devtool workspace
Comment 12 Douglas Royds 2021-04-07 05:14:15 UTC
I have succeeded in reproducing this.
I'm working on a solution.
Comment 13 Prabin CA 2021-04-07 05:16:09 UTC
Thanks Douglas
Comment 15 Prabin CA 2021-04-08 08:39:18 UTC
Thanks Douglas, Appreciate your effort. I had applied this patches locally, this resolve the hazard.
Now waiting for to merge into oe-core/poky.
Comment 16 Prabin CA 2021-04-20 06:59:53 UTC
Thanks Douglass. these patches have merged into oe-core and poky, hence closing the Bugzilla tickets.
Comment 18 Randy MacLeod 2021-05-25 01:32:31 UTC
Fixed by: https://git.openembedded.org/openembedded-core/commit/meta/classes?id=1c18225d3ef94a41fc073ae87c163b68e6d46571

$ git branch -a --contains 1c18225d3ef94a41fc073ae87c163b68e6d46571
* master
  master-next

Thanks everyone.