[PATCH 0/3] meta: 3 fixes

[PATCH 0/3] meta: 3 fixes

[Robert Yang]

The following changes since commit 95fced137a46dc98863fe5af7be5cbce708602f2:

  udev-extraconf: introduce multiple blacklist files for more complex setups (2016-01-05 17:55:05 +0000)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/3fixes
  http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/3fixes

Robert Yang (3):
  cogl-1.0: fix may be used uninitialized error
  run-postinsts: can't be allarch
  liberation-fonts: can't be allarch

 .../run-postinsts/run-postinsts_1.0.bb             |    2 +-
 ...ce-culling.c-fix-may-be-used-uninitialize.patch |   35 ++++++++++++++++++++
 meta/recipes-graphics/cogl/cogl-1.0_1.22.0.bb      |    2 ++
 .../ttf-fonts/liberation-fonts_1.04.bb             |    2 +-
 4 files changed, 39 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-graphics/cogl/cogl-1.0/test-backface-culling.c-fix-may-be-used-uninitialize.patch

-- 
1.7.9.5

[PATCH 1/3] cogl-1.0: fix may be used uninitialized error

[Robert Yang]

Fixed when DEBUG_BUILD = "1":
test-backface-culling.c:206:7: error: 'cull_front' may be used uninitialized in this function [-Werror=maybe-uninitialized]
|        validate_part (framebuffer,
|        ^
| cc1: some warnings being treated as errors

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
 ...ce-culling.c-fix-may-be-used-uninitialize.patch |   35 ++++++++++++++++++++
 meta/recipes-graphics/cogl/cogl-1.0_1.22.0.bb      |    2 ++
 2 files changed, 37 insertions(+)
 create mode 100644 meta/recipes-graphics/cogl/cogl-1.0/test-backface-culling.c-fix-may-be-used-uninitialize.patch

diff --git a/meta/recipes-graphics/cogl/cogl-1.0/test-backface-culling.c-fix-may-be-used-uninitialize.patch b/meta/recipes-graphics/cogl/cogl-1.0/test-backface-culling.c-fix-may-be-used-uninitialize.patch
new file mode 100644
index 0000000..479a0ff
--- /dev/null
+++ b/meta/recipes-graphics/cogl/cogl-1.0/test-backface-culling.c-fix-may-be-used-uninitialize.patch
@@ -0,0 +1,35 @@
+From a51f61d675a0e7d6649182c6a1325ceab8342df2 Mon Sep 17 00:00:00 2001
+From: Robert Yang <liezhi.yang@windriver.com>
+Date: Mon, 4 Jan 2016 22:47:29 -0800
+Subject: [PATCH] test-backface-culling.c: fix may be used uninitialized error
+
+Fixed when gcc -O:
+test-backface-culling.c:206:7: error: 'cull_front' may be used uninitialized in this function [-Werror=maybe-uninitialized]
+|        validate_part (framebuffer,
+|        ^
+| cc1: some warnings being treated as errors
+
+Upstream-Status: Pending
+
+Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
+---
+ tests/conform/test-backface-culling.c |    3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/tests/conform/test-backface-culling.c b/tests/conform/test-backface-culling.c
+index e90c2f5..7c45592 100644
+--- a/tests/conform/test-backface-culling.c
++++ b/tests/conform/test-backface-culling.c
+@@ -164,7 +164,8 @@ validate_result (CoglFramebuffer *framebuffer, int y_offset)
+ 
+   for (draw_num = 0; draw_num < 16; draw_num++)
+     {
+-      CoglBool cull_front, cull_back;
++      CoglBool cull_front = FALSE;
++      CoglBool cull_back = FALSE;
+       CoglPipelineCullFaceMode cull_mode;
+ 
+       if (USE_LEGACY_STATE (draw_num))
+-- 
+1.7.9.5
+
diff --git a/meta/recipes-graphics/cogl/cogl-1.0_1.22.0.bb b/meta/recipes-graphics/cogl/cogl-1.0_1.22.0.bb
index 3b1e199..ed10c7a 100644
--- a/meta/recipes-graphics/cogl/cogl-1.0_1.22.0.bb
+++ b/meta/recipes-graphics/cogl/cogl-1.0_1.22.0.bb
@@ -1,5 +1,7 @@
 require cogl-1.0.inc
 
+SRC_URI += "file://test-backface-culling.c-fix-may-be-used-uninitialize.patch"
+
 LIC_FILES_CHKSUM = "file://COPYING;md5=1b1a508d91d25ca607c83f92f3e31c84"
 SRC_URI[archive.md5sum] = "ab684ec96848d79d22757fb3064820c8"
 SRC_URI[archive.sha256sum] = "689dfb5d14fc1106e9d2ded0f7930dcf7265d0bc84fa846b4f03941633eeaa91"
-- 
1.7.9.5

[PATCH 2/3] run-postinsts: can't be allarch

[Robert Yang]

The dependencies chain:
run-postinsts -> update-rc.d.bbclass -> initscripts -> update-alternatives.

The update-alternatives is provided by opkg-utils which is not allarch.

This caused a problem:
$ bitbake lib32-core-image-minimal

Both lib32-opkg-utils and opkg-utils would be built, but opkg-utils
shouldn't, this patch can fix the problem.

[YOCTO #8879]

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
 .../run-postinsts/run-postinsts_1.0.bb             |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/run-postinsts/run-postinsts_1.0.bb b/meta/recipes-devtools/run-postinsts/run-postinsts_1.0.bb
index 11c94e5..6b4290c 100644
--- a/meta/recipes-devtools/run-postinsts/run-postinsts_1.0.bb
+++ b/meta/recipes-devtools/run-postinsts/run-postinsts_1.0.bb
@@ -11,7 +11,7 @@ SRC_URI = "file://run-postinsts \
 
 S = "${WORKDIR}"
 
-inherit allarch systemd update-rc.d
+inherit systemd update-rc.d
 
 INITSCRIPT_NAME = "run-postinsts"
 INITSCRIPT_PARAMS = "start 99 S ."
-- 
1.7.9.5

Re: [PATCH 2/3] run-postinsts: can't be allarch

[Richard Purdie]

On Wed, 2016-01-06 at 23:45 -0800, Robert Yang wrote:
> The dependencies chain:
> run-postinsts -> update-rc.d.bbclass -> initscripts -> update
> -alternatives.
> 
> The update-alternatives is provided by opkg-utils which is not
> allarch.
> 
> This caused a problem:
> $ bitbake lib32-core-image-minimal
> 
> Both lib32-opkg-utils and opkg-utils would be built, but opkg-utils
> shouldn't, this patch can fix the problem.
> 
> [YOCTO #8879]
> 
> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
> ---
>  .../run-postinsts/run-postinsts_1.0.bb             |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Removing allarch isn't the correct way to fix this, we need to figure
out what is going wrong and fix multilib.

Cheers,

Richard

Re: [PATCH 2/3] run-postinsts: can't be allarch

[Robert Yang]

On 01/07/2016 06:57 PM, Richard Purdie wrote:
> On Wed, 2016-01-06 at 23:45 -0800, Robert Yang wrote:
>> The dependencies chain:
>> run-postinsts -> update-rc.d.bbclass -> initscripts -> update
>> -alternatives.
>>
>> The update-alternatives is provided by opkg-utils which is not
>> allarch.
>>
>> This caused a problem:
>> $ bitbake lib32-core-image-minimal
>>
>> Both lib32-opkg-utils and opkg-utils would be built, but opkg-utils
>> shouldn't, this patch can fix the problem.
>>
>> [YOCTO #8879]
>>
>> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
>> ---
>>   .../run-postinsts/run-postinsts_1.0.bb             |    2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> Removing allarch isn't the correct way to fix this, we need to figure
> out what is going wrong and fix multilib.

Thanks, I will try to fix it from multilib.

// Robert

>
> Cheers,
>
> Richard
>

Re: [PATCH 2/3] run-postinsts: can't be allarch

[Robert Yang]

On 01/07/2016 06:57 PM, Richard Purdie wrote:
> On Wed, 2016-01-06 at 23:45 -0800, Robert Yang wrote:
>> The dependencies chain:
>> run-postinsts -> update-rc.d.bbclass -> initscripts -> update
>> -alternatives.
>>
>> The update-alternatives is provided by opkg-utils which is not
>> allarch.
>>
>> This caused a problem:
>> $ bitbake lib32-core-image-minimal
>>
>> Both lib32-opkg-utils and opkg-utils would be built, but opkg-utils
>> shouldn't, this patch can fix the problem.
>>
>> [YOCTO #8879]
>>
>> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
>> ---
>>   .../run-postinsts/run-postinsts_1.0.bb             |    2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> Removing allarch isn't the correct way to fix this, we need to figure
> out what is going wrong and fix multilib.

After more investigations, the problem is for allarch recipe such as
run-postinsts:
$ bitbake lib32-run-postinsts

No lib32 recipes was built, but 64bit python, flex, openssl and
others are built since lib32-allarch recipe is the same as allarch
one. (the dependencies chain:
run-postinsts -> update-rc.d.bbclass -> initscripts -> 
update-alternatives-opkg-utils)

I think that SIGGEN_EXCLUDERECIPES_ABISAFE is for recipes which depend on
the abisafe ones, not for abisafe ones depend on otheres.

I'm still thinking how to fix it, any suggestions is appreciated.

// Robert

>
> Cheers,
>
> Richard
>

Re: [PATCH 2/3] run-postinsts: can't be allarch

[Robert Yang]

On 01/07/2016 06:57 PM, Richard Purdie wrote:
> On Wed, 2016-01-06 at 23:45 -0800, Robert Yang wrote:
>> The dependencies chain:
>> run-postinsts -> update-rc.d.bbclass -> initscripts -> update
>> -alternatives.
>>
>> The update-alternatives is provided by opkg-utils which is not
>> allarch.
>>
>> This caused a problem:
>> $ bitbake lib32-core-image-minimal
>>
>> Both lib32-opkg-utils and opkg-utils would be built, but opkg-utils
>> shouldn't, this patch can fix the problem.
>>
>> [YOCTO #8879]
>>
>> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
>> ---
>>   .../run-postinsts/run-postinsts_1.0.bb             |    2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> Removing allarch isn't the correct way to fix this, we need to figure
> out what is going wrong and fix multilib.

After more investigations, it seems that there is no easy way to fix
the problem, maybe we need choose not fix it atm. Here is a short summary.

* Problem
   When mutilib is enabled, for example:
   MACHINE ?= "qemux86-64"
   require conf/multilib.conf
   MULTILIBS = "multilib:lib32"
   DEFAULTTUNE_virtclass-multilib-lib32 = "x86"

   $ bitbake core-image-minimal

   We will see that a few 64 bit pkgs will be built, for example, 64 bit
   python, bash, openssl, opkg-utils and, but they shouldn't, since it
   doesn't make any sense to build them since they are not going to be
   installed on the target by default.

* Root Cause
   This is caused by run-postinsts is allarch since:
   $ bitbake lib32-run-postinsts
   run-postinsts (no lib32 since it is an allarch pkg) would be built,
   it depends on non-allarch recipe opkg-utils, and opkg-utils depends
   on others, a simple graph.

   core-image-minimal       ->  run-postinsts           -> opkg-utils
   lib32-core-image-minimal ->  (lib32-)run-postinsts   -> opkg-utils (should be 
lib32)

   We can see that lib32-run-postinsts breaks multilib's dependencies chain,
   and there is no easy way fix the problem AFAIK.

* What I have tried
   - Extend allarch to lib32-allarch, this would changed a lot on allarch,
     and if we extend it, allarch is not really "all arch".

   - Let each recipe provides a lib32allarch-recipe when extend multilib,
     which is used for allarch recipe depends on it, and let bitbake decide
     which to run for example:

     opkg-utils        *provides* lib32allarch-opkg-utils
     lib32-opkg-utils  *provides* lib32allarch-opkg-utils
     And then:
     run-postinsts     *depends*  lib32allarch-opkg-utils

     Both opkg-utils and lib32-opkg-utils provides lib32allarch-opkg-utils,
     then let bitbake choose a proper to build according what you are building,
     (lib32-recipe -> lib32-opkg-utils, recipe -> opkg-utils) this also
     need modify bitbake's PREFERRENCE_PROVIDER policies, which seems not worth,
     so I drop this idea.

Any suggestions is appreciated.

// Robert

>
> Cheers,
>
> Richard
>

[PATCH 3/3] liberation-fonts: can't be allarch

[Robert Yang]

liberation-fonts inherit fontcache which would depend on fontconfig, and
fontconfig is not allarch, so that liberation-fonts can't be allarch.

It caused a problem:
$ bitbake lib32-core-image-sato

Both lib32-fontconfig and fontconfig would be built, but fontconfig
shouldn't, this patch can fix the problem.

[YOCTO #8882]

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
 .../ttf-fonts/liberation-fonts_1.04.bb             |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/ttf-fonts/liberation-fonts_1.04.bb b/meta/recipes-graphics/ttf-fonts/liberation-fonts_1.04.bb
index bda82e7..f64748c 100644
--- a/meta/recipes-graphics/ttf-fonts/liberation-fonts_1.04.bb
+++ b/meta/recipes-graphics/ttf-fonts/liberation-fonts_1.04.bb
@@ -13,7 +13,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
 PR = "r4"
 PE = "1"
 
-inherit allarch fontcache
+inherit fontcache
 
 FONT_PACKAGES = "${PN}"
 
-- 
1.7.9.5

Re: [PATCH 3/3] liberation-fonts: can't be allarch

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1767 bytes --]

On Wed, Jan 06, 2016 at 11:45:24PM -0800, Robert Yang wrote:
> liberation-fonts inherit fontcache which would depend on fontconfig, and
> fontconfig is not allarch, so that liberation-fonts can't be allarch.
> 
> It caused a problem:
> $ bitbake lib32-core-image-sato
> 
> Both lib32-fontconfig and fontconfig would be built, but fontconfig
> shouldn't, this patch can fix the problem.
> 
> [YOCTO #8882]

liberation-fonts excludes fontconfig dependency since:
commit 0b5e868d160faca041cda42b670066facd4db531
Author: Richard Purdie <richard.purdie@linuxfoundation.org>
Date:   Tue Aug 25 17:58:12 2015 +0100

    layer.conf: Add several allarch dependency exclusions

If it doesn't work then you probably should remove the entry from
layer.conf as well.

> 
> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
> ---
>  .../ttf-fonts/liberation-fonts_1.04.bb             |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-graphics/ttf-fonts/liberation-fonts_1.04.bb b/meta/recipes-graphics/ttf-fonts/liberation-fonts_1.04.bb
> index bda82e7..f64748c 100644
> --- a/meta/recipes-graphics/ttf-fonts/liberation-fonts_1.04.bb
> +++ b/meta/recipes-graphics/ttf-fonts/liberation-fonts_1.04.bb
> @@ -13,7 +13,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
>  PR = "r4"
>  PE = "1"
>  
> -inherit allarch fontcache
> +inherit fontcache
>  
>  FONT_PACKAGES = "${PN}"
>  
> -- 
> 1.7.9.5
> 
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: [PATCH 3/3] liberation-fonts: can't be allarch

[Phil Blundell]

On Wed, 2016-01-06 at 23:45 -0800, Robert Yang wrote:
> liberation-fonts inherit fontcache which would depend on fontconfig, 
> and fontconfig is not allarch, so that liberation-fonts can't be
> allarch.

This doesn't make any sense.  I don't think allarch is, or ever has
been, contagious in that way.  There is no good reason I can think of
to require that all the dependencies of an allarch package should
themselves be allarch.  Indeed, if we did require this then it would
probably mean that virtually no packages could legitimately be allarch.

p.

Re: [PATCH 3/3] liberation-fonts: can't be allarch

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1764 bytes --]

On Thu, Jan 07, 2016 at 12:16:44PM +0000, Phil Blundell wrote:
> On Wed, 2016-01-06 at 23:45 -0800, Robert Yang wrote:
> > liberation-fonts inherit fontcache which would depend on fontconfig, 
> > and fontconfig is not allarch, so that liberation-fonts can't be
> > allarch.
> 
> This doesn't make any sense.  I don't think allarch is, or ever has
> been, contagious in that way.  There is no good reason I can think of
> to require that all the dependencies of an allarch package should
> themselves be allarch.  Indeed, if we did require this then it would
> probably mean that virtually no packages could legitimately be allarch.

Current implementation requires that, because if there is dependency on
TUNE_PKGARCH or MACHINE_ARCH recipe, then this "allarch" recipe will be
rebuilt (or at least different archive is unpacked from sstate) every
single time you switch MACHINE.

That's why there is SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS and
SIGGEN_EXCLUDERECIPES_ABISAFE for sstate code to skip some dependencies
like this - but that doesn't remove the dependency only says that the
allarch recipe doesn't need to be rebuilt when the dependency signature
was modified.

Marking recipe as allarch incorrectly is worse than leaving it
TUNE_PKGARCH, because as TUNE_PKGARCH it's rebuilt once per architecture
and the stamps are valid until next metadata change, with incorrect
allarch it's also rebuilt once per architecture (or MACHINE), but also
unpacked from sstate every time you change the MACHINE (even when the
resulting packages end in the same directory with the same filename -
except when PRservice changes the last number in EXTENDPRAUTO with each
MACHINE change).

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: [PATCH 3/3] liberation-fonts: can't be allarch

[Robert Yang]

Hi Martin,

Here is a new patch which can fix allarch's mutilib dependencies issues,
can you see any potential problems with this patch, please ?

Subject: [PATCH] multilib.bbclass: extend allarch recipes

Extend allarch recipes, this can fix multilib dependencies issues, for
example:
$ bitbake lib32-run-postinsts
No 64 bit recipes should be built, but the fact was *no 32 bit* recipes
were built, this was because "bitbake lib32-run-postinsts" was the same as
"bitbake run-postinsts" since we didn't extend allarch recipes.

Extend allarch recipes just as allarch packagegroups will fix the
problem.

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
  meta/classes/multilib.bbclass        |    4 ----
  meta/classes/multilib_global.bbclass |    4 +---
  meta/classes/package.bbclass         |    6 ------
  3 files changed, 1 insertion(+), 13 deletions(-)

diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index 75e91fa..514588e 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -46,10 +46,6 @@ python multilib_virtclass_handler () {
      if bb.data.inherits_class('nativesdk', e.data) or 
bb.data.inherits_class('crosssdk', e.data):
          raise bb.parse.SkipPackage("We can't extend nativesdk recipes")

-    if bb.data.inherits_class('allarch', e.data) and not 
bb.data.inherits_class('packagegroup', e.data):
-        raise bb.parse.SkipPackage("Don't extend allarch recipes which are not 
packagegroups")
-
-
      # Expand this since this won't work correctly once we set a multilib into 
place
      e.data.setVar("ALL_MULTILIB_PACKAGE_ARCHS", 
e.data.getVar("ALL_MULTILIB_PACKAGE_ARCHS", True))

diff --git a/meta/classes/multilib_global.bbclass 
b/meta/classes/multilib_global.bbclass
index 67dc72b..2c115d5 100644
--- a/meta/classes/multilib_global.bbclass
+++ b/meta/classes/multilib_global.bbclass
@@ -143,9 +143,7 @@ python multilib_virtclass_handler_global () {

      if isinstance(e, bb.event.RecipeParsed) and not variant:
          if bb.data.inherits_class('kernel', e.data) or \
-            bb.data.inherits_class('module-base', e.data) or \
-            (bb.data.inherits_class('allarch', e.data) and\
-             not bb.data.inherits_class('packagegroup', e.data)):
+            bb.data.inherits_class('module-base', e.data):
              variants = (e.data.getVar("MULTILIB_VARIANTS", True) or "").split()

              import oe.classextend
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index c51a4e8..697b4d2 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -1294,9 +1294,6 @@ python emit_pkgdata() {
      if bb.data.inherits_class('kernel', d) or 
bb.data.inherits_class('module-base', d):
          write_extra_pkgs(variants, pn, packages, pkgdatadir)

-    if (bb.data.inherits_class('allarch', d) and not 
bb.data.inherits_class('packagegroup', d)):
-        write_extra_pkgs(global_variants, pn, packages, pkgdatadir)
-
      workdir = d.getVar('WORKDIR', True)

      for pkg in packages.split():
@@ -1377,9 +1374,6 @@ python emit_pkgdata() {
      if bb.data.inherits_class('kernel', d) or 
bb.data.inherits_class('module-base', d):
          write_extra_runtime_pkgs(variants, packages, pkgdatadir)

-    if bb.data.inherits_class('allarch', d) and not 
bb.data.inherits_class('packagegroup', d):
-        write_extra_runtime_pkgs(global_variants, packages, pkgdatadir)
-
      bb.utils.unlockfile(lf)
  }
  emit_pkgdata[dirs] = "${PKGDESTWORK}/runtime ${PKGDESTWORK}/runtime-reverse 
${PKGDESTWORK}/runtime-rprovides"
-- 
1.7.9.5

// Robert

On 01/07/2016 08:55 PM, Martin Jansa wrote:
> On Thu, Jan 07, 2016 at 12:16:44PM +0000, Phil Blundell wrote:
>> On Wed, 2016-01-06 at 23:45 -0800, Robert Yang wrote:
>>> liberation-fonts inherit fontcache which would depend on fontconfig,
>>> and fontconfig is not allarch, so that liberation-fonts can't be
>>> allarch.
>>
>> This doesn't make any sense.  I don't think allarch is, or ever has
>> been, contagious in that way.  There is no good reason I can think of
>> to require that all the dependencies of an allarch package should
>> themselves be allarch.  Indeed, if we did require this then it would
>> probably mean that virtually no packages could legitimately be allarch.
>
> Current implementation requires that, because if there is dependency on
> TUNE_PKGARCH or MACHINE_ARCH recipe, then this "allarch" recipe will be
> rebuilt (or at least different archive is unpacked from sstate) every
> single time you switch MACHINE.
>
> That's why there is SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS and
> SIGGEN_EXCLUDERECIPES_ABISAFE for sstate code to skip some dependencies
> like this - but that doesn't remove the dependency only says that the
> allarch recipe doesn't need to be rebuilt when the dependency signature
> was modified.
>
> Marking recipe as allarch incorrectly is worse than leaving it
> TUNE_PKGARCH, because as TUNE_PKGARCH it's rebuilt once per architecture
> and the stamps are valid until next metadata change, with incorrect
> allarch it's also rebuilt once per architecture (or MACHINE), but also
> unpacked from sstate every time you change the MACHINE (even when the
> resulting packages end in the same directory with the same filename -
> except when PRservice changes the last number in EXTENDPRAUTO with each
> MACHINE change).
>

Re: [PATCH 3/3] liberation-fonts: can't be allarch

[Robert Yang]

Sorry, there are problems, for example:
lib32-tzdata and tzdata:
/path/to/tmp/sysroots/qemux86-64/usr/share/zoneinfo/Brazil/East
  Matched in manifest-qemux86-64-lib32-tzdata.populate_sysroot
Please verify which recipe should provide the above files.

// Robert

On 01/13/2016 01:56 PM, Robert Yang wrote:
>
> Hi Martin,
>
> Here is a new patch which can fix allarch's mutilib dependencies issues,
> can you see any potential problems with this patch, please ?
>
> Subject: [PATCH] multilib.bbclass: extend allarch recipes
>
> Extend allarch recipes, this can fix multilib dependencies issues, for
> example:
> $ bitbake lib32-run-postinsts
> No 64 bit recipes should be built, but the fact was *no 32 bit* recipes
> were built, this was because "bitbake lib32-run-postinsts" was the same as
> "bitbake run-postinsts" since we didn't extend allarch recipes.
>
> Extend allarch recipes just as allarch packagegroups will fix the
> problem.
>
> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
> ---
>   meta/classes/multilib.bbclass        |    4 ----
>   meta/classes/multilib_global.bbclass |    4 +---
>   meta/classes/package.bbclass         |    6 ------
>   3 files changed, 1 insertion(+), 13 deletions(-)
>
> diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
> index 75e91fa..514588e 100644
> --- a/meta/classes/multilib.bbclass
> +++ b/meta/classes/multilib.bbclass
> @@ -46,10 +46,6 @@ python multilib_virtclass_handler () {
>       if bb.data.inherits_class('nativesdk', e.data) or
> bb.data.inherits_class('crosssdk', e.data):
>           raise bb.parse.SkipPackage("We can't extend nativesdk recipes")
>
> -    if bb.data.inherits_class('allarch', e.data) and not
> bb.data.inherits_class('packagegroup', e.data):
> -        raise bb.parse.SkipPackage("Don't extend allarch recipes which are not
> packagegroups")
> -
> -
>       # Expand this since this won't work correctly once we set a multilib into
> place
>       e.data.setVar("ALL_MULTILIB_PACKAGE_ARCHS",
> e.data.getVar("ALL_MULTILIB_PACKAGE_ARCHS", True))
>
> diff --git a/meta/classes/multilib_global.bbclass
> b/meta/classes/multilib_global.bbclass
> index 67dc72b..2c115d5 100644
> --- a/meta/classes/multilib_global.bbclass
> +++ b/meta/classes/multilib_global.bbclass
> @@ -143,9 +143,7 @@ python multilib_virtclass_handler_global () {
>
>       if isinstance(e, bb.event.RecipeParsed) and not variant:
>           if bb.data.inherits_class('kernel', e.data) or \
> -            bb.data.inherits_class('module-base', e.data) or \
> -            (bb.data.inherits_class('allarch', e.data) and\
> -             not bb.data.inherits_class('packagegroup', e.data)):
> +            bb.data.inherits_class('module-base', e.data):
>               variants = (e.data.getVar("MULTILIB_VARIANTS", True) or "").split()
>
>               import oe.classextend
> diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
> index c51a4e8..697b4d2 100644
> --- a/meta/classes/package.bbclass
> +++ b/meta/classes/package.bbclass
> @@ -1294,9 +1294,6 @@ python emit_pkgdata() {
>       if bb.data.inherits_class('kernel', d) or
> bb.data.inherits_class('module-base', d):
>           write_extra_pkgs(variants, pn, packages, pkgdatadir)
>
> -    if (bb.data.inherits_class('allarch', d) and not
> bb.data.inherits_class('packagegroup', d)):
> -        write_extra_pkgs(global_variants, pn, packages, pkgdatadir)
> -
>       workdir = d.getVar('WORKDIR', True)
>
>       for pkg in packages.split():
> @@ -1377,9 +1374,6 @@ python emit_pkgdata() {
>       if bb.data.inherits_class('kernel', d) or
> bb.data.inherits_class('module-base', d):
>           write_extra_runtime_pkgs(variants, packages, pkgdatadir)
>
> -    if bb.data.inherits_class('allarch', d) and not
> bb.data.inherits_class('packagegroup', d):
> -        write_extra_runtime_pkgs(global_variants, packages, pkgdatadir)
> -
>       bb.utils.unlockfile(lf)
>   }
>   emit_pkgdata[dirs] = "${PKGDESTWORK}/runtime ${PKGDESTWORK}/runtime-reverse
> ${PKGDESTWORK}/runtime-rprovides"