meta: 3 fixes

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

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

---
 ...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

new file mode 100644
index 0000000..479a0ff
@@ -0,0 +1,35 @@
+From a51f61d675a0e7d6649182c6a1325ceab8342df2 Mon Sep 17 00:00:00 2001
+From: Robert Yang <[email protected]>
+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 <[email protected]>
+---
+ 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
+

index 3b1e199..ed10c7a 100644
@@ -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

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]

---
 .../run-postinsts/run-postinsts_1.0.bb             |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 11c94e5..6b4290c 100644
@@ -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

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

Cheers,

Richard

Thanks, I will try to fix it from multilib.

// Robert

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

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

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]

---
 .../ttf-fonts/liberation-fonts_1.04.bb             |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index bda82e7..f64748c 100644
@@ -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

liberation-fonts excludes fontconfig dependency since:
commit 0b5e868d160faca041cda42b670066facd4db531

Author: Richard Purdie <[email protected]>
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.

Martin 'JaMa' Jansa     jabber: [email protected]

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.

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: [email protected]

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.

---
 meta/classes/multilib.bbclass        |    4 ----
 meta/classes/multilib_global.bbclass |    4 +---
 meta/classes/package.bbclass         |    6 ------
 3 files changed, 1 insertion(+), 13 deletions(-)

index 75e91fa..514588e 100644
@@ -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))

index 67dc72b..2c115d5 100644
@@ -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

index c51a4e8..697b4d2 100644
@@ -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

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