Skip to contentSkip to conversation

multilib.bbclass/package_manager.py: fix <multilib>-meta-toolchain build failure

PATCH In review Hongxu Jia 2 participants 4 messages Oct 15, 2014

lore
Share & tools
lore

Hongxu Jia

author
#0 lore raw

v3 cover multilib.bbclass/package_manager.py: fix <multilib>-meta-toolchain build failure

Changed in V3:
Comparisons to singletons like None should always be done 'is not'

Changed in V2:
V1 caused build failure of meta-toolchain, in order to avoid it, we should use DEFAULTTUNE_virtclass-multilib-lib32 first, if it is not available, and try to use DEFAULTTUNE_ML_<multilib>

Test steps:

1. env
vim local.conf
...
MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS ?= "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 ?= "x86"
...

2. build lib32-meta-toolchain success

$ bitbake lib32-meta-toolchain

3. build meta-toolchain success

$ bitbake meta-toolchain

//Hongxu

The following changes since commit ccf5a4d2342c4fd40e4e0b332ea7e34e0bf175d4:

build-appliance-image: Update to dizzy head revision (2014-10-11 08:11:17 +0100)

are available in the git repository at:

git://git.pokylinux.org/poky-contrib hongxu/fix-lib32-meta-toolchain
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/fix-lib32-meta-toolchain

Hongxu Jia (1):
multilib.bbclass/package_manager.py: fix <multilib>-meta-toolchain
build failure

 meta/classes/multilib.bbclass  | 1 +
 meta/lib/oe/package_manager.py | 3 +++
 2 files changed, 4 insertions(+)
Signature · 1 line
1.9.1
author
#1 lore raw

PATCH v3 1/1 multilib.bbclass/package_manager.py: fix <multilib>-meta-toolchain build failure

There is a failure to build lib32-meta-toolchain:
...
|ERROR: lib32-packagegroup-core-standalone-sdk-target not found in the base feeds (qemux86_64 x86 noarch any all).
...

In package_manager.py, the variable 'DEFAULTTUNE_virtclass-multilib-lib32' is used to process multilib image/toolchain. But for the build of lib32- meta-toolchain, the value of 'DEFAULTTUNE_virtclass-multilib-lib32' is deleted. In 'bitbake lib32-meta-toolchain -e', we got:
...

|# $DEFAULTTUNE_virtclass-multilib-lib32 [2 operations]
|#   set? /home/jiahongxu/yocto/build-20141010-yocto/conf/local.conf:237
|#     "x86"
|#   del data_smart.py:406 [finalize]
|#     ""
|# pre-expansion value:
|#   "None"

...

The commit 899d45b90061eb3cf3e71029072eee42cd80930c in oe-core deleted it at DataSmart.finalize
...

Author: Richard Purdie <[email protected]>
Date:   Tue May 31 23:52:50 2011 +0100

bitbake/data_smart: Change overrides behaviour to remove
expanded variables from the datastore
...

We add an internal variable 'DEFAULTTUNE_ML_<multilib>', assign it with the value of 'DEFAULTTUNE_virtclass-multilib-lib32' before deleting.

For rpm backend in package_manager.py, we use DEFAULTTUNE_virtclass-multilib -lib32 first, if it is not available, and try to use DEFAULTTUNE_ML_<multilib>

[YOCTO #6842]

Signed-off-by Hongxu Jia <[email protected]>
---
 meta/classes/multilib.bbclass  | 1 +
 meta/lib/oe/package_manager.py | 3 +++
 2 files changed, 4 insertions(+)
meta/classes/multilib.bbclass +1 -0
index 6e143dd..6aad894 100644
@@ -60,6 +60,7 @@ python multilib_virtclass_handler () {
     newtune = e.data.getVar("DEFAULTTUNE_" + "virtclass-multilib-" + variant, False)
     if newtune:
         e.data.setVar("DEFAULTTUNE", newtune)
+        e.data.setVar('DEFAULTTUNE_ML_%s' % variant, newtune)
 }
 
 addhandler multilib_virtclass_handler
meta/lib/oe/package_manager.py +3 -0
index 27fdf26..221b38a 100644
@@ -63,6 +63,9 @@ class RpmIndexer(Indexer):
                     localdata = bb.data.createCopy(self.d)
                     default_tune_key = "DEFAULTTUNE_virtclass-multilib-" + eext[1]
                     default_tune = localdata.getVar(default_tune_key, False)
+                    if default_tune is None:
+                        default_tune_key = "DEFAULTTUNE_ML_" + eext[1]
+                        default_tune = localdata.getVar(default_tune_key, False)
                     if default_tune:
                         localdata.setVar("DEFAULTTUNE", default_tune)
                         bb.data.update_data(localdata)
Signature · 1 line
1.9.1
#2 lore raw

Hi Hongxu,

Out of curiosity, was this broken since 2011? Because the commit you're mentioning is more than 3 years old and I'm not totally convinced that it's the one triggering the problem...

laurentiu

Quoted 78 lines · Hongxu Jia

There is a failure to build lib32-meta-toolchain:
...
|ERROR: lib32-packagegroup-core-standalone-sdk-target not found in the base feeds (qemux86_64 x86 noarch any all).
...

In package_manager.py, the variable 'DEFAULTTUNE_virtclass-multilib-lib32' is used to process multilib image/toolchain. But for the build of lib32- meta-toolchain, the value of 'DEFAULTTUNE_virtclass-multilib-lib32' is deleted. In 'bitbake lib32-meta-toolchain -e', we got:
...

|# $DEFAULTTUNE_virtclass-multilib-lib32 [2 operations]
|#   set? /home/jiahongxu/yocto/build-20141010-yocto/conf/local.conf:237
|#     "x86"
|#   del data_smart.py:406 [finalize]
|#     ""
|# pre-expansion value:
|#   "None"

...

The commit 899d45b90061eb3cf3e71029072eee42cd80930c in oe-core deleted it at DataSmart.finalize
...

Author: Richard Purdie <[email protected]>
Date:   Tue May 31 23:52:50 2011 +0100

bitbake/data_smart: Change overrides behaviour to remove
expanded variables from the datastore
...

We add an internal variable 'DEFAULTTUNE_ML_<multilib>', assign it with the value of 'DEFAULTTUNE_virtclass-multilib-lib32' before deleting.

For rpm backend in package_manager.py, we use DEFAULTTUNE_virtclass-multilib -lib32 first, if it is not available, and try to use DEFAULTTUNE_ML_<multilib>

[YOCTO #6842]

Signed-off-by Hongxu Jia <[email protected]>
---
 meta/classes/multilib.bbclass  | 1 +
 meta/lib/oe/package_manager.py | 3 +++
 2 files changed, 4 insertions(+)
meta/classes/multilib.bbclass +1 -0
index 6e143dd..6aad894 100644
@@ -60,6 +60,7 @@ python multilib_virtclass_handler () {
     newtune = e.data.getVar("DEFAULTTUNE_" + "virtclass-multilib-" + variant, False)
     if newtune:
         e.data.setVar("DEFAULTTUNE", newtune)
+        e.data.setVar('DEFAULTTUNE_ML_%s' % variant, newtune)
 }
 
 addhandler multilib_virtclass_handler
meta/lib/oe/package_manager.py +3 -0
index 27fdf26..221b38a 100644
@@ -63,6 +63,9 @@ class RpmIndexer(Indexer):
                     localdata = bb.data.createCopy(self.d)
                     default_tune_key = "DEFAULTTUNE_virtclass-multilib-" + eext[1]
                     default_tune = localdata.getVar(default_tune_key, False)
+                    if default_tune is None:
+                        default_tune_key = "DEFAULTTUNE_ML_" + eext[1]
+                        default_tune = localdata.getVar(default_tune_key, False)
                     if default_tune:
                         localdata.setVar("DEFAULTTUNE", default_tune)
                         bb.data.update_data(localdata)
Signature · 7 lines
1.9.1

-- 
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
author
#3 lore raw
Quoted 5 lines · Laurentiu Palcu

Hi Hongxu,

Out of curiosity, was this broken since 2011? Because the commit you're mentioning is more than 3 years old and I'm not totally convinced that it's the one triggering the problem...

It failed after do_rootfs refactor, in previous version, the code of using 'DEFAULTTUNE_virtclass-multilib-lib32' by rpm located in python __anonymous () {
}
which not invoking data_smart.finalize. At that time, everyting is ok.

//Hongxu

Quoted 78 lines
Quoted 78 lines

There is a failure to build lib32-meta-toolchain:
...
|ERROR: lib32-packagegroup-core-standalone-sdk-target not found in the base feeds (qemux86_64 x86 noarch any all).
...

In package_manager.py, the variable 'DEFAULTTUNE_virtclass-multilib-lib32' is used to process multilib image/toolchain. But for the build of lib32- meta-toolchain, the value of 'DEFAULTTUNE_virtclass-multilib-lib32' is deleted. In 'bitbake lib32-meta-toolchain -e', we got:
...

|# $DEFAULTTUNE_virtclass-multilib-lib32 [2 operations]
|#   set? /home/jiahongxu/yocto/build-20141010-yocto/conf/local.conf:237
|#     "x86"
|#   del data_smart.py:406 [finalize]
|#     ""
|# pre-expansion value:
|#   "None"

...

The commit 899d45b90061eb3cf3e71029072eee42cd80930c in oe-core deleted it at DataSmart.finalize
...

Author: Richard Purdie <[email protected]>
Date:   Tue May 31 23:52:50 2011 +0100

bitbake/data_smart: Change overrides behaviour to remove
expanded variables from the datastore
...

We add an internal variable 'DEFAULTTUNE_ML_<multilib>', assign it with the value of 'DEFAULTTUNE_virtclass-multilib-lib32' before deleting.

For rpm backend in package_manager.py, we use DEFAULTTUNE_virtclass-multilib -lib32 first, if it is not available, and try to use DEFAULTTUNE_ML_<multilib>

[YOCTO #6842]

Signed-off-by Hongxu Jia <[email protected]>
---
  meta/classes/multilib.bbclass  | 1 +
  meta/lib/oe/package_manager.py | 3 +++
  2 files changed, 4 insertions(+)
meta/classes/multilib.bbclass +1 -0
index 6e143dd..6aad894 100644
@@ -60,6 +60,7 @@ python multilib_virtclass_handler () {
      newtune = e.data.getVar("DEFAULTTUNE_" + "virtclass-multilib-" + variant, False)
      if newtune:
          e.data.setVar("DEFAULTTUNE", newtune)
+        e.data.setVar('DEFAULTTUNE_ML_%s' % variant, newtune)
  }
 
  addhandler multilib_virtclass_handler
meta/lib/oe/package_manager.py +3 -0
index 27fdf26..221b38a 100644
@@ -63,6 +63,9 @@ class RpmIndexer(Indexer):
                      localdata = bb.data.createCopy(self.d)
                      default_tune_key = "DEFAULTTUNE_virtclass-multilib-" + eext[1]
                      default_tune = localdata.getVar(default_tune_key, False)
+                    if default_tune is None:
+                        default_tune_key = "DEFAULTTUNE_ML_" + eext[1]
+                        default_tune = localdata.getVar(default_tune_key, False)
                      if default_tune:
                          localdata.setVar("DEFAULTTUNE", default_tune)
                          bb.data.update_data(localdata)
Signature · 7 lines
1.9.1

-- 
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core