Date   

How to set PACKAGE_EXTRA_ARCHS

Måns Zigher <mans.zigher@...>
 

Hi,

I am facing an issue described here
https://lists.yoctoproject.org/pipermail/yocto/2019-June/045565.html.
I have come to the conclusion that I need to add armv7ahf-neon-mx8mm
to PACKAGE_EXTRA_ARCHS but it is not obvious how to do that based on
what is stated in the reference manual
https://www.yoctoproject.org/docs/2.4/ref-manual/ref-manual.html#var-PACKAGE_EXTRA_ARCHS,
at least not for me. I have gone through the existing usage of the
PACKAGE_EXTRA_ARCHS in poky but in there it is always used in
combination with tune so for example

PACKAGE_EXTRA_ARCHS_tune-armv7atb-neon =
"${PACKAGE_EXTRA_ARCHS_tune-armv7atb} armv7ab-neon armv7at2b-neon"

How can I make sure to get armv7ahf-neon-mx8mm added to the
PACKAGE_EXTRA_ARCHS variable and where should it be set local.conf,
machine configuration?

BR
Måns Zigher


Minutes: Yocto Project Technical Team Meeting 6/4/2019

Reyna, David
 

Yocto Project Technical Team Meeting
MINUTES: 6/4/2019
 
Attendees: Richard, Armin, JoshuaW, Bruce, Michael, Randy, Scott, Alejandro, RobW, Ross, MichaelH, Tim, Vineela, David, Trevor, Sajal
 
RP:
  * YP-2.6 M1 for this coming Monday
  * ptest dependencies are improving, and we are getting better results
  * M1 at risk for patchtest, RP and Paul are working on it
  * Key change for M1 is GCC9, and we working on a few regressions
  * Need people to work on the NEWCOMER defects
  * Joshua is working on the autobuilder
  * Randy: Kevin will be pinged on the QEMU issue (PPC?)
 
Armin: Fedora Core 30 for M!? RP: we could add workers today to test that host. RP: FYI, we did get funding for updated build servers.
 
Armin: Question about “xe” support, issue with supporting two tarball compressions. Evidently some hosts, and especially some containers, do not have an tar that supports –J (specifically Thud) or do not have “xe”. RP mentions that the Thud documentation does require “xe”.
 
Randy: PTest improvements a priority for M2? RP: GCC9, bluez, and acl priorities for fixing.
 
Scott: Any specific help he can provide 2.8? There was mention of SPDX headers done but not licenses, more ptest, ARM autobuilder.
 
RP: Want to achieve for 2.8:
  * Ptest
  * License
  * reproducibility
  * hash equivalency important, needs updates to runqueue to implement,
 
Hash equivalency only as good as builds are reproducible. Mention that simple changes to perl rdepends can have a deep cascade effect. The feature needs to look at what changed, know that nothing really changed, and then substitute same hash and save un-needed rebuild. For example “perl-native’ rebuilds, look to see that it is binary equivalent (bit by bit). Another more flexible (but probably later) technique could be elf symbol comparison for equivalency. RP: goal is to make the checker pluggable so that enhancements are easy. Richard mentioned that it might be worth taking a month off of his daily merge tasks just to get this feature done.
 
Randy: Is there idle time we can use? Perhaps in some timezone like China? RP: usually fires off builds at end of his day, so not real idle timezone.
 
RP: can use help in getting pull requests together
 
RP: Automated tests, provable reproducible builds important to our upstream cred.
 
Scott: Meta-agl-v2? It has become hard to maintain, stale dependencies, no security patching, obsolete components.
 
RP: anything we are missing? Randy touched on Rust. RP: nice for 2.9, but reproducibility more important.
 
Tim: Meta-virtualization into core? Perhaps for 2.9. Meta-python? Split off V2 support to separate repo.
 
- David
 
 


[meta-security][master][warrior][PATCH] bastille: solved the conflict with perl-module-text-wrap and base-files

zangrc
 

-Remove the link to perl5 to resolve the conflict with perl-module-text-wrap.

-Remove the operation on /var/lock to resolve the conflict with base-files.

Signed-off-by: Zang Ruochen <zangrc.fnst@cn.fujitsu.com>
---
recipes-security/bastille/bastille_3.2.1.bb | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/recipes-security/bastille/bastille_3.2.1.bb b/recipes-security/bastille/bastille_3.2.1.bb
index 152c03a..e9accb5 100644
--- a/recipes-security/bastille/bastille_3.2.1.bb
+++ b/recipes-security/bastille/bastille_3.2.1.bb
@@ -41,8 +41,7 @@ S = "${WORKDIR}/Bastille"

do_install () {
install -d ${D}${sbindir}
- install -d ${D}${libdir}/perl/site_perl/Curses
- ln -sf perl ${D}/${libdir}/perl5
+ install -d ${D}${libdir}/perl5/site_perl/Curses

install -d ${D}${libdir}/Bastille
install -d ${D}${libdir}/Bastille/API
@@ -51,7 +50,6 @@ do_install () {
install -d ${D}${datadir}/Bastille/OSMap/Modules
install -d ${D}${datadir}/Bastille/Questions
install -d ${D}${datadir}/Bastille/FKL/configs/
- install -d ${D}${localstatedir}/lock/subsys/bastille
install -d ${D}${localstatedir}/log/Bastille
install -d ${D}${sysconfdir}/Bastille
install -m 0755 AutomatedBastille ${D}${sbindir}
--
2.20.1


QA issue [configure-unsafe] when compiling vlc

Ori Pessach
 

Hi,

I'm trying to compile vlc 3.0.6 as part of my image from the recipe found here:


When bitbake configures the source, I get the following error:

ERROR: vlc-3.0.6-r0 do_configure: QA Issue: This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities.
Rerun configure task after fixing this. [configure-unsafe]
ERROR: vlc-3.0.6-r0 do_configure: Fatal QA errors found, failing task.
ERROR: vlc-3.0.6-r0 do_configure:
ERROR: vlc-3.0.6-r0 do_configure: Function failed: do_qa_configure
ERROR: Logfile of failure stored in: /home/ori/projects/poky/build/tmp/work/core2-64-poky-linux/vlc/3.0.6-r0/temp/log.do_configure.14767
ERROR: Task (/home/ori/projects/poky/meta-openembedded/meta-multimedia/recipes-multimedia/vlc/vlc_3.0.6.bb:do_configure) failed with exit code '1'

I looked in the log, and the problem happens when checking for the existence of live555 - the configure script outputs this:

configure:32517: x86_64-poky-linux-g++  -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse -fstack-protector-strong  -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/home/ori/projects/poky/build/tmp/work/core2-64-poky-linux/vlc/3.0.6-r0/recipe-sysroot -E  -I/usr/include/liveMedia -I/usr/include/groupsock -I/usr/include/BasicUsageEnvironment -I/usr/include/UsageEnvironment conftest.cpp
cc1plus: warning: include location "/usr/include/liveMedia" is unsafe for cross-compilation [-Wpoison-system-directories]
cc1plus: warning: include location "/usr/include/groupsock" is unsafe for cross-compilation [-Wpoison-system-directories]
cc1plus: warning: include location "/usr/include/BasicUsageEnvironment" is unsafe for cross-compilation [-Wpoison-system-directories]
cc1plus: warning: include location "/usr/include/UsageEnvironment" is unsafe for cross-compilation [-Wpoison-system-directories]

I verified that the include directories are in /usr/include/ under the sysroot specified above, and I, say, move /usr/include/liveMedia out of the way, compilation fails when the compiler doesn't find the headers, so it doesn't seem like it's even looking under sysroot.

Any idea how I can fix this?

Thanks,

Ori


[meta-anaconda][PATCH] anaconda_oe.py: add ldconfig to DISTRO_FEATURES

Chen Qi
 

'ldconfig' is a required distro feature for anaconda, so add it
before running any builds, otherwise, we get build failure due to
lack of 'ldconfig'.

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
---
lib/oeqa/selftest/cases/anaconda_oe.py | 1 +
1 file changed, 1 insertion(+)

diff --git a/lib/oeqa/selftest/cases/anaconda_oe.py b/lib/oeqa/selftest/cases/anaconda_oe.py
index 9cc6de4..e568709 100644
--- a/lib/oeqa/selftest/cases/anaconda_oe.py
+++ b/lib/oeqa/selftest/cases/anaconda_oe.py
@@ -19,6 +19,7 @@ class TestAnacondaOE(OESelftestTestCase):
features += 'VIRTUAL-RUNTIME_init_manager = "systemd"\n'
features += 'DISTRO_FEATURES_append = " systemd"\n'
features += 'DISTRO_FEATURES_append = " pam"\n'
+ features += 'DISTRO_FEATURES_append = " ldconfig"\n'
features += 'DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " sysvinit"\n'
self.write_config(features)
self.logger.info('local.conf:\n%s' % features)
--
2.7.4


warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) #warning

Robert Berger <yocto.user.mailinglist@...>
 

Hi,

I can see in some examples:

warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O)

which can be fixed by passing the proper CFLAGS.

Unfortunately the warning is only visible in log files.

1) Is there a way to show compiler warnings when you bitbake on the console (without -DDD and/or -v and filtering for warning:)

2) How would you add a check for this to insane.bbclass?

Regards,

Robert


Re: Potential (?) systemd YOCTO problems

Morne
 

On Tue, Jun 04, 2019 at 11:34:15PM +0200, Zoran Stojsavljevic wrote:
(I did not find it anywhere in the manuals, maybe I missed the paragraph - please, advice where it is?).
This is where I found it previously:
https://www.yoctoproject.org/docs/2.7/dev-manual/dev-manual.html#using-systemd-exclusively

Thank you again,
Glad I could help.

- Morné


Re: [meta-gplv2][PATCH] elfutils: ignore new error from gcc-9

Ross Burton
 

Pushed, thanks.

Ross

On Wed, 5 Jun 2019 at 08:56, Martin Jansa <martin.jansa@gmail.com> wrote:

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
recipes-devtools/elfutils/elfutils_0.148.bb | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/recipes-devtools/elfutils/elfutils_0.148.bb b/recipes-devtools/elfutils/elfutils_0.148.bb
index a03b74e..1f07a28 100644
--- a/recipes-devtools/elfutils/elfutils_0.148.bb
+++ b/recipes-devtools/elfutils/elfutils_0.148.bb
@@ -57,6 +57,10 @@ SRC_URI += "\
"
inherit autotools gettext

+# There is a fix in 0.175 version (https://sourceware.org/bugzilla/show_bug.cgi?id=23884)
+# but 0.175 has different license, so to be safe don't backport the fix, just ignore the issue
+CFLAGS += "-Wno-error=missing-attributes"
+
EXTRA_OECONF = "--program-prefix=eu- --without-lzma"
EXTRA_OECONF_append_class-native = " --without-bzlib"
EXTRA_OECONF_append_libc-uclibc = " --enable-uclibc"
--
2.17.1

--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


git fetcher - AUTOREV and best practices

Maciej Pijanowski
 

Hello,

As explained in the mega manual [1], when using the git:// fetcher,
setting the
SRCREV to ${AUTOREV} will result in building the latest commit from
given git
branch (master, if not specified otherwise).

Using AUTOREV feature in recipe has following implications as far as I
can see:

- the same recipe might get built using different git commit, depending
on when
  the build was run, which breaks the reproducibility,
- it imposes some potential security risk - by specifying the exact
commit in
  the recipe, we can at least say that this revision of this package is fine
  and we want to build it; with AUTOREV we might not be aware of the
code we're
  fetching

I'm wondering whether there are any best practices or strict rules
written down
for recipes getting upstream to follow in this area. When inspecting some of
the layers from the git.yoctoprojects.org, it appears that the AUTOREV
feature
is almost not used, besides a few exceptions.

I'm wondering whether it would make sense to raise a warning when git
fetcher
with AUTOREV is used, so it would be easier to build on top OE / Yocto with
reproducibility / security in mind.

I understand that this feature is mostly meant for development purposes. I'm
just looking for a tools how one could easily make sure that each
fetched source code
is verified prior compilation.

I've already looked at the https:// fetcher (which is mostly used for
fetching tarballs).
It requires the recipe to contain valid md5 and sha256 sums. Even if we
suppress the
error in case checksum mismatch in the recipe by setting the
BB_STRICT_CHECKSUM
to 0, we are still getting the warning, which is the desired behavior I
believe.


[1]:
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-AUTOREV
[2]:
https://www.yoctoproject.org/docs/2.0.1/bitbake-user-manual/bitbake-user-manual.html#var-BB_STRICT_CHECKSUM

--
Maciej Pijanowski
Embedded Systems Engineer
https://3mdeb.com | @3mdeb_com


Re: [multilib] No Manifest file generated from: lib32-alsa-lib

Måns Zigher <mans.zigher@...>
 

So it looks like I should include armv7ahf-neon-mx8mm to
PACKAGE_EXTRA_ARCHS but I am unsure how to do that any ideas?

/Måns

Den ons 5 juni 2019 kl 14:05 skrev Måns Zigher <mans.zigher@gmail.com>:


Looking in the env dump I can see that meta-freescale is overwriting
the PACKAGE_ARCH in a alsa-lib_%.bbappend

PACKAGE_ARCH_imx = "${MACHINE_SOCARCH}"

/Måns

Den ons 5 juni 2019 kl 14:04 skrev Måns Zigher <mans.zigher@gmail.com>:

So running bitbake -e lib32-alsa-lib I can see the following

# $SSTATE_MANMACH [2 operations]
# set? /home/extzig/Workspace/mozart-workspace/layers/poky/meta/classes/sstate.bbclass:54
# "${SSTATE_PKGARCH}"
# set sstate.bbclass:94
[__anon_105__home_extzig_Workspace_mozart_workspace_layers_poky_meta_classes_sstate_bbclass]
# "armv7ahf-neon-mx8mm"
# pre-expansion value:
# "armv7ahf-neon-mx8mm"
SSTATE_MANMACH="armv7ahf-neon-mx8mm"

So first the SSTATE_MANMACH variable is set to

SSTATE_MANMACH ?= "${SSTATE_PKGARCH}"

at line 54 in sstate.bbclass but then it will be overwritten at line 94 to

d.setVar('SSTATE_MANMACH', d.expand("${PACKAGE_ARCH}"))

The code that results in this looks like

if bb.data.inherits_class('native', d):
d.setVar('SSTATE_PKGARCH', d.getVar('BUILD_ARCH', False))
elif bb.data.inherits_class('crosssdk', d):
d.setVar('SSTATE_PKGARCH',
d.expand("${BUILD_ARCH}_${SDK_ARCH}_${SDK_OS}"))
elif bb.data.inherits_class('cross', d):
d.setVar('SSTATE_PKGARCH', d.expand("${BUILD_ARCH}_${TARGET_ARCH}"))
elif bb.data.inherits_class('nativesdk', d):
d.setVar('SSTATE_PKGARCH', d.expand("${SDK_ARCH}_${SDK_OS}"))
elif bb.data.inherits_class('cross-canadian', d):
d.setVar('SSTATE_PKGARCH', d.expand("${SDK_ARCH}_${PACKAGE_ARCH}"))
elif bb.data.inherits_class('allarch', d) and
d.getVar("PACKAGE_ARCH") == "all":
d.setVar('SSTATE_PKGARCH', "allarch")
else:
d.setVar('SSTATE_MANMACH', d.expand("${PACKAGE_ARCH}"))

So I guess either PACKAGE_ARCH is screwed up for alsa-lib or I should
not get to that else statement.

/Måns

Den ons 5 juni 2019 kl 13:39 skrev Måns Zigher <mans.zigher@gmail.com>:

I have the following manifest files

find . -name "manifest*-lib32-alsa-lib*"
./manifest-mimx8mm-lib32-alsa-lib.packagedata
./manifest-armv7ahf-neon-mx8mm-lib32-alsa-lib.package_write_rpm
./manifest-armv7ahf-neon-mx8mm-lib32-alsa-lib.package

but find_sstate_manifest called from package_manager

./meta/lib/oe/package_manager.py:615: manifest, d2 =
oe.sstatesig.find_sstate_manifest(c, taskdepdata[dep][2], taskname, d,
multilibs)
./meta/lib/oe/sstatesig.py:372:def find_sstate_manifest(taskdata,
taskdata2, taskname, d, multilibcache):

will only look for

manifest-armv7at2hf-neon-lib32-alsa-lib.package_write_rpm
manifest-armv7ahf-neon-lib32-alsa-lib.package_write_rpm

I am not sure why the mx8mm is added to the lib32-alsa-lib manifest
file since this is not added to any other package when building it for
lib32.

/Måns

Den ons 5 juni 2019 kl 13:00 skrev Måns Zigher <mans.zigher@gmail.com>:

I think this looks wrong
"manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm" I
have not intentionally added lib32-alsa-lib to the nativesdk part so I
am not sure why it expects to find that?

/Måns

Den ons 5 juni 2019 kl 12:46 skrev Måns Zigher <mans.zigher@gmail.com>:

When checking the build for lib32-alsa-lib there is no rpm package created

deploy-rpms/armv7ahf_neon_mx8mm# ls
lib32-alsa-conf-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-alsa-server-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-libasound2-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-libasound-dbg-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-libasound-dev-1.1.5-r0.armv7ahf_neon_mx8mm.rpm

it matches the alsa-lib build also when checking the list of packages by running

oe-pkgdata-util list-pkg-files -p lib32-alsa-lib and oe-pkgdata-util
list-pkg-files -p alsa-lib

there is a package lib32-alsa-lib and alsa-lib so why is there no rpm
for this package? I would have thought that that should be the case?

/Måns

Den ons 5 juni 2019 kl 11:06 skrev Måns Zigher <mans.zigher@gmail.com>:

Hi,

I am trying to build an SDK where I have multilib enabled in my
local.conf but I am encountering this error message

WARNING: strix-sdk-1.0-r0 do_populate_sdk: Manifest
/workdir/builds/imx8mm/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm
not found in mimx8mm aarch64-mx8mm armv7at2hf-neon armv7ahf-neon
armv7at2hf-vfp armv7ahf-vfp armv6thf-vfp armv6hf-vfp armv5tehf-vfp
armv5ehf-vfp armv5thf-vfp armv5hf-vfp allarch x86_64_x86_64-nativesdk
(variant 'lib32')?
ERROR: strix-sdk-1.0-r0 do_populate_sdk: No manifest generated from:
lib32-alsa-lib in
virtual:multilib:lib32:/workdir/layers/poky/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb
ERROR: strix-sdk-1.0-r0 do_populate_sdk: Function failed: do_populate_sdk

I am currently using poky sumo could not see that anything have
changed in alsa-lib except bumping it to 1.1.6 in thud. I have tried
go through the code in both

./poky/meta/lib/oe/package_manager.py

and

./poky/meta/lib/oe/sstatesig.py

to see if I could understand why there is no manifest file created for
lib32-alsa-lib but without any luck. What task should I run to create
the Manifest file? Any other pointers to where I should look to
understand this issue is appreciated.

BR
Måns Zigher


Re: [multilib] No Manifest file generated from: lib32-alsa-lib

Måns Zigher <mans.zigher@...>
 

Looking in the env dump I can see that meta-freescale is overwriting
the PACKAGE_ARCH in a alsa-lib_%.bbappend

PACKAGE_ARCH_imx = "${MACHINE_SOCARCH}"

/Måns

Den ons 5 juni 2019 kl 14:04 skrev Måns Zigher <mans.zigher@gmail.com>:


So running bitbake -e lib32-alsa-lib I can see the following

# $SSTATE_MANMACH [2 operations]
# set? /home/extzig/Workspace/mozart-workspace/layers/poky/meta/classes/sstate.bbclass:54
# "${SSTATE_PKGARCH}"
# set sstate.bbclass:94
[__anon_105__home_extzig_Workspace_mozart_workspace_layers_poky_meta_classes_sstate_bbclass]
# "armv7ahf-neon-mx8mm"
# pre-expansion value:
# "armv7ahf-neon-mx8mm"
SSTATE_MANMACH="armv7ahf-neon-mx8mm"

So first the SSTATE_MANMACH variable is set to

SSTATE_MANMACH ?= "${SSTATE_PKGARCH}"

at line 54 in sstate.bbclass but then it will be overwritten at line 94 to

d.setVar('SSTATE_MANMACH', d.expand("${PACKAGE_ARCH}"))

The code that results in this looks like

if bb.data.inherits_class('native', d):
d.setVar('SSTATE_PKGARCH', d.getVar('BUILD_ARCH', False))
elif bb.data.inherits_class('crosssdk', d):
d.setVar('SSTATE_PKGARCH',
d.expand("${BUILD_ARCH}_${SDK_ARCH}_${SDK_OS}"))
elif bb.data.inherits_class('cross', d):
d.setVar('SSTATE_PKGARCH', d.expand("${BUILD_ARCH}_${TARGET_ARCH}"))
elif bb.data.inherits_class('nativesdk', d):
d.setVar('SSTATE_PKGARCH', d.expand("${SDK_ARCH}_${SDK_OS}"))
elif bb.data.inherits_class('cross-canadian', d):
d.setVar('SSTATE_PKGARCH', d.expand("${SDK_ARCH}_${PACKAGE_ARCH}"))
elif bb.data.inherits_class('allarch', d) and
d.getVar("PACKAGE_ARCH") == "all":
d.setVar('SSTATE_PKGARCH', "allarch")
else:
d.setVar('SSTATE_MANMACH', d.expand("${PACKAGE_ARCH}"))

So I guess either PACKAGE_ARCH is screwed up for alsa-lib or I should
not get to that else statement.

/Måns

Den ons 5 juni 2019 kl 13:39 skrev Måns Zigher <mans.zigher@gmail.com>:

I have the following manifest files

find . -name "manifest*-lib32-alsa-lib*"
./manifest-mimx8mm-lib32-alsa-lib.packagedata
./manifest-armv7ahf-neon-mx8mm-lib32-alsa-lib.package_write_rpm
./manifest-armv7ahf-neon-mx8mm-lib32-alsa-lib.package

but find_sstate_manifest called from package_manager

./meta/lib/oe/package_manager.py:615: manifest, d2 =
oe.sstatesig.find_sstate_manifest(c, taskdepdata[dep][2], taskname, d,
multilibs)
./meta/lib/oe/sstatesig.py:372:def find_sstate_manifest(taskdata,
taskdata2, taskname, d, multilibcache):

will only look for

manifest-armv7at2hf-neon-lib32-alsa-lib.package_write_rpm
manifest-armv7ahf-neon-lib32-alsa-lib.package_write_rpm

I am not sure why the mx8mm is added to the lib32-alsa-lib manifest
file since this is not added to any other package when building it for
lib32.

/Måns

Den ons 5 juni 2019 kl 13:00 skrev Måns Zigher <mans.zigher@gmail.com>:

I think this looks wrong
"manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm" I
have not intentionally added lib32-alsa-lib to the nativesdk part so I
am not sure why it expects to find that?

/Måns

Den ons 5 juni 2019 kl 12:46 skrev Måns Zigher <mans.zigher@gmail.com>:

When checking the build for lib32-alsa-lib there is no rpm package created

deploy-rpms/armv7ahf_neon_mx8mm# ls
lib32-alsa-conf-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-alsa-server-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-libasound2-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-libasound-dbg-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-libasound-dev-1.1.5-r0.armv7ahf_neon_mx8mm.rpm

it matches the alsa-lib build also when checking the list of packages by running

oe-pkgdata-util list-pkg-files -p lib32-alsa-lib and oe-pkgdata-util
list-pkg-files -p alsa-lib

there is a package lib32-alsa-lib and alsa-lib so why is there no rpm
for this package? I would have thought that that should be the case?

/Måns

Den ons 5 juni 2019 kl 11:06 skrev Måns Zigher <mans.zigher@gmail.com>:

Hi,

I am trying to build an SDK where I have multilib enabled in my
local.conf but I am encountering this error message

WARNING: strix-sdk-1.0-r0 do_populate_sdk: Manifest
/workdir/builds/imx8mm/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm
not found in mimx8mm aarch64-mx8mm armv7at2hf-neon armv7ahf-neon
armv7at2hf-vfp armv7ahf-vfp armv6thf-vfp armv6hf-vfp armv5tehf-vfp
armv5ehf-vfp armv5thf-vfp armv5hf-vfp allarch x86_64_x86_64-nativesdk
(variant 'lib32')?
ERROR: strix-sdk-1.0-r0 do_populate_sdk: No manifest generated from:
lib32-alsa-lib in
virtual:multilib:lib32:/workdir/layers/poky/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb
ERROR: strix-sdk-1.0-r0 do_populate_sdk: Function failed: do_populate_sdk

I am currently using poky sumo could not see that anything have
changed in alsa-lib except bumping it to 1.1.6 in thud. I have tried
go through the code in both

./poky/meta/lib/oe/package_manager.py

and

./poky/meta/lib/oe/sstatesig.py

to see if I could understand why there is no manifest file created for
lib32-alsa-lib but without any luck. What task should I run to create
the Manifest file? Any other pointers to where I should look to
understand this issue is appreciated.

BR
Måns Zigher


Re: [multilib] No Manifest file generated from: lib32-alsa-lib

Måns Zigher <mans.zigher@...>
 

So running bitbake -e lib32-alsa-lib I can see the following

# $SSTATE_MANMACH [2 operations]
# set? /home/extzig/Workspace/mozart-workspace/layers/poky/meta/classes/sstate.bbclass:54
# "${SSTATE_PKGARCH}"
# set sstate.bbclass:94
[__anon_105__home_extzig_Workspace_mozart_workspace_layers_poky_meta_classes_sstate_bbclass]
# "armv7ahf-neon-mx8mm"
# pre-expansion value:
# "armv7ahf-neon-mx8mm"
SSTATE_MANMACH="armv7ahf-neon-mx8mm"

So first the SSTATE_MANMACH variable is set to

SSTATE_MANMACH ?= "${SSTATE_PKGARCH}"

at line 54 in sstate.bbclass but then it will be overwritten at line 94 to

d.setVar('SSTATE_MANMACH', d.expand("${PACKAGE_ARCH}"))

The code that results in this looks like

if bb.data.inherits_class('native', d):
d.setVar('SSTATE_PKGARCH', d.getVar('BUILD_ARCH', False))
elif bb.data.inherits_class('crosssdk', d):
d.setVar('SSTATE_PKGARCH',
d.expand("${BUILD_ARCH}_${SDK_ARCH}_${SDK_OS}"))
elif bb.data.inherits_class('cross', d):
d.setVar('SSTATE_PKGARCH', d.expand("${BUILD_ARCH}_${TARGET_ARCH}"))
elif bb.data.inherits_class('nativesdk', d):
d.setVar('SSTATE_PKGARCH', d.expand("${SDK_ARCH}_${SDK_OS}"))
elif bb.data.inherits_class('cross-canadian', d):
d.setVar('SSTATE_PKGARCH', d.expand("${SDK_ARCH}_${PACKAGE_ARCH}"))
elif bb.data.inherits_class('allarch', d) and
d.getVar("PACKAGE_ARCH") == "all":
d.setVar('SSTATE_PKGARCH', "allarch")
else:
d.setVar('SSTATE_MANMACH', d.expand("${PACKAGE_ARCH}"))

So I guess either PACKAGE_ARCH is screwed up for alsa-lib or I should
not get to that else statement.

/Måns

Den ons 5 juni 2019 kl 13:39 skrev Måns Zigher <mans.zigher@gmail.com>:


I have the following manifest files

find . -name "manifest*-lib32-alsa-lib*"
./manifest-mimx8mm-lib32-alsa-lib.packagedata
./manifest-armv7ahf-neon-mx8mm-lib32-alsa-lib.package_write_rpm
./manifest-armv7ahf-neon-mx8mm-lib32-alsa-lib.package

but find_sstate_manifest called from package_manager

./meta/lib/oe/package_manager.py:615: manifest, d2 =
oe.sstatesig.find_sstate_manifest(c, taskdepdata[dep][2], taskname, d,
multilibs)
./meta/lib/oe/sstatesig.py:372:def find_sstate_manifest(taskdata,
taskdata2, taskname, d, multilibcache):

will only look for

manifest-armv7at2hf-neon-lib32-alsa-lib.package_write_rpm
manifest-armv7ahf-neon-lib32-alsa-lib.package_write_rpm

I am not sure why the mx8mm is added to the lib32-alsa-lib manifest
file since this is not added to any other package when building it for
lib32.

/Måns

Den ons 5 juni 2019 kl 13:00 skrev Måns Zigher <mans.zigher@gmail.com>:

I think this looks wrong
"manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm" I
have not intentionally added lib32-alsa-lib to the nativesdk part so I
am not sure why it expects to find that?

/Måns

Den ons 5 juni 2019 kl 12:46 skrev Måns Zigher <mans.zigher@gmail.com>:

When checking the build for lib32-alsa-lib there is no rpm package created

deploy-rpms/armv7ahf_neon_mx8mm# ls
lib32-alsa-conf-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-alsa-server-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-libasound2-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-libasound-dbg-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-libasound-dev-1.1.5-r0.armv7ahf_neon_mx8mm.rpm

it matches the alsa-lib build also when checking the list of packages by running

oe-pkgdata-util list-pkg-files -p lib32-alsa-lib and oe-pkgdata-util
list-pkg-files -p alsa-lib

there is a package lib32-alsa-lib and alsa-lib so why is there no rpm
for this package? I would have thought that that should be the case?

/Måns

Den ons 5 juni 2019 kl 11:06 skrev Måns Zigher <mans.zigher@gmail.com>:

Hi,

I am trying to build an SDK where I have multilib enabled in my
local.conf but I am encountering this error message

WARNING: strix-sdk-1.0-r0 do_populate_sdk: Manifest
/workdir/builds/imx8mm/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm
not found in mimx8mm aarch64-mx8mm armv7at2hf-neon armv7ahf-neon
armv7at2hf-vfp armv7ahf-vfp armv6thf-vfp armv6hf-vfp armv5tehf-vfp
armv5ehf-vfp armv5thf-vfp armv5hf-vfp allarch x86_64_x86_64-nativesdk
(variant 'lib32')?
ERROR: strix-sdk-1.0-r0 do_populate_sdk: No manifest generated from:
lib32-alsa-lib in
virtual:multilib:lib32:/workdir/layers/poky/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb
ERROR: strix-sdk-1.0-r0 do_populate_sdk: Function failed: do_populate_sdk

I am currently using poky sumo could not see that anything have
changed in alsa-lib except bumping it to 1.1.6 in thud. I have tried
go through the code in both

./poky/meta/lib/oe/package_manager.py

and

./poky/meta/lib/oe/sstatesig.py

to see if I could understand why there is no manifest file created for
lib32-alsa-lib but without any luck. What task should I run to create
the Manifest file? Any other pointers to where I should look to
understand this issue is appreciated.

BR
Måns Zigher


Re: [multilib] No Manifest file generated from: lib32-alsa-lib

Måns Zigher <mans.zigher@...>
 

I have the following manifest files

find . -name "manifest*-lib32-alsa-lib*"
./manifest-mimx8mm-lib32-alsa-lib.packagedata
./manifest-armv7ahf-neon-mx8mm-lib32-alsa-lib.package_write_rpm
./manifest-armv7ahf-neon-mx8mm-lib32-alsa-lib.package

but find_sstate_manifest called from package_manager

./meta/lib/oe/package_manager.py:615: manifest, d2 =
oe.sstatesig.find_sstate_manifest(c, taskdepdata[dep][2], taskname, d,
multilibs)
./meta/lib/oe/sstatesig.py:372:def find_sstate_manifest(taskdata,
taskdata2, taskname, d, multilibcache):

will only look for

manifest-armv7at2hf-neon-lib32-alsa-lib.package_write_rpm
manifest-armv7ahf-neon-lib32-alsa-lib.package_write_rpm

I am not sure why the mx8mm is added to the lib32-alsa-lib manifest
file since this is not added to any other package when building it for
lib32.

/Måns

Den ons 5 juni 2019 kl 13:00 skrev Måns Zigher <mans.zigher@gmail.com>:


I think this looks wrong
"manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm" I
have not intentionally added lib32-alsa-lib to the nativesdk part so I
am not sure why it expects to find that?

/Måns

Den ons 5 juni 2019 kl 12:46 skrev Måns Zigher <mans.zigher@gmail.com>:

When checking the build for lib32-alsa-lib there is no rpm package created

deploy-rpms/armv7ahf_neon_mx8mm# ls
lib32-alsa-conf-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-alsa-server-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-libasound2-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-libasound-dbg-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-libasound-dev-1.1.5-r0.armv7ahf_neon_mx8mm.rpm

it matches the alsa-lib build also when checking the list of packages by running

oe-pkgdata-util list-pkg-files -p lib32-alsa-lib and oe-pkgdata-util
list-pkg-files -p alsa-lib

there is a package lib32-alsa-lib and alsa-lib so why is there no rpm
for this package? I would have thought that that should be the case?

/Måns

Den ons 5 juni 2019 kl 11:06 skrev Måns Zigher <mans.zigher@gmail.com>:

Hi,

I am trying to build an SDK where I have multilib enabled in my
local.conf but I am encountering this error message

WARNING: strix-sdk-1.0-r0 do_populate_sdk: Manifest
/workdir/builds/imx8mm/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm
not found in mimx8mm aarch64-mx8mm armv7at2hf-neon armv7ahf-neon
armv7at2hf-vfp armv7ahf-vfp armv6thf-vfp armv6hf-vfp armv5tehf-vfp
armv5ehf-vfp armv5thf-vfp armv5hf-vfp allarch x86_64_x86_64-nativesdk
(variant 'lib32')?
ERROR: strix-sdk-1.0-r0 do_populate_sdk: No manifest generated from:
lib32-alsa-lib in
virtual:multilib:lib32:/workdir/layers/poky/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb
ERROR: strix-sdk-1.0-r0 do_populate_sdk: Function failed: do_populate_sdk

I am currently using poky sumo could not see that anything have
changed in alsa-lib except bumping it to 1.1.6 in thud. I have tried
go through the code in both

./poky/meta/lib/oe/package_manager.py

and

./poky/meta/lib/oe/sstatesig.py

to see if I could understand why there is no manifest file created for
lib32-alsa-lib but without any luck. What task should I run to create
the Manifest file? Any other pointers to where I should look to
understand this issue is appreciated.

BR
Måns Zigher


Re: [multilib] No Manifest file generated from: lib32-alsa-lib

Måns Zigher <mans.zigher@...>
 

I think this looks wrong
"manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm" I
have not intentionally added lib32-alsa-lib to the nativesdk part so I
am not sure why it expects to find that?

/Måns

Den ons 5 juni 2019 kl 12:46 skrev Måns Zigher <mans.zigher@gmail.com>:


When checking the build for lib32-alsa-lib there is no rpm package created

deploy-rpms/armv7ahf_neon_mx8mm# ls
lib32-alsa-conf-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-alsa-server-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-libasound2-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-libasound-dbg-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-libasound-dev-1.1.5-r0.armv7ahf_neon_mx8mm.rpm

it matches the alsa-lib build also when checking the list of packages by running

oe-pkgdata-util list-pkg-files -p lib32-alsa-lib and oe-pkgdata-util
list-pkg-files -p alsa-lib

there is a package lib32-alsa-lib and alsa-lib so why is there no rpm
for this package? I would have thought that that should be the case?

/Måns

Den ons 5 juni 2019 kl 11:06 skrev Måns Zigher <mans.zigher@gmail.com>:

Hi,

I am trying to build an SDK where I have multilib enabled in my
local.conf but I am encountering this error message

WARNING: strix-sdk-1.0-r0 do_populate_sdk: Manifest
/workdir/builds/imx8mm/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm
not found in mimx8mm aarch64-mx8mm armv7at2hf-neon armv7ahf-neon
armv7at2hf-vfp armv7ahf-vfp armv6thf-vfp armv6hf-vfp armv5tehf-vfp
armv5ehf-vfp armv5thf-vfp armv5hf-vfp allarch x86_64_x86_64-nativesdk
(variant 'lib32')?
ERROR: strix-sdk-1.0-r0 do_populate_sdk: No manifest generated from:
lib32-alsa-lib in
virtual:multilib:lib32:/workdir/layers/poky/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb
ERROR: strix-sdk-1.0-r0 do_populate_sdk: Function failed: do_populate_sdk

I am currently using poky sumo could not see that anything have
changed in alsa-lib except bumping it to 1.1.6 in thud. I have tried
go through the code in both

./poky/meta/lib/oe/package_manager.py

and

./poky/meta/lib/oe/sstatesig.py

to see if I could understand why there is no manifest file created for
lib32-alsa-lib but without any luck. What task should I run to create
the Manifest file? Any other pointers to where I should look to
understand this issue is appreciated.

BR
Måns Zigher


Re: [multilib] No Manifest file generated from: lib32-alsa-lib

Måns Zigher <mans.zigher@...>
 

When checking the build for lib32-alsa-lib there is no rpm package created

deploy-rpms/armv7ahf_neon_mx8mm# ls
lib32-alsa-conf-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-alsa-server-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-libasound2-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-libasound-dbg-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-libasound-dev-1.1.5-r0.armv7ahf_neon_mx8mm.rpm

it matches the alsa-lib build also when checking the list of packages by running

oe-pkgdata-util list-pkg-files -p lib32-alsa-lib and oe-pkgdata-util
list-pkg-files -p alsa-lib

there is a package lib32-alsa-lib and alsa-lib so why is there no rpm
for this package? I would have thought that that should be the case?

/Måns

Den ons 5 juni 2019 kl 11:06 skrev Måns Zigher <mans.zigher@gmail.com>:


Hi,

I am trying to build an SDK where I have multilib enabled in my
local.conf but I am encountering this error message

WARNING: strix-sdk-1.0-r0 do_populate_sdk: Manifest
/workdir/builds/imx8mm/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm
not found in mimx8mm aarch64-mx8mm armv7at2hf-neon armv7ahf-neon
armv7at2hf-vfp armv7ahf-vfp armv6thf-vfp armv6hf-vfp armv5tehf-vfp
armv5ehf-vfp armv5thf-vfp armv5hf-vfp allarch x86_64_x86_64-nativesdk
(variant 'lib32')?
ERROR: strix-sdk-1.0-r0 do_populate_sdk: No manifest generated from:
lib32-alsa-lib in
virtual:multilib:lib32:/workdir/layers/poky/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb
ERROR: strix-sdk-1.0-r0 do_populate_sdk: Function failed: do_populate_sdk

I am currently using poky sumo could not see that anything have
changed in alsa-lib except bumping it to 1.1.6 in thud. I have tried
go through the code in both

./poky/meta/lib/oe/package_manager.py

and

./poky/meta/lib/oe/sstatesig.py

to see if I could understand why there is no manifest file created for
lib32-alsa-lib but without any luck. What task should I run to create
the Manifest file? Any other pointers to where I should look to
understand this issue is appreciated.

BR
Måns Zigher


Re: fitImage kernel compression type

Måns Zigher <mans.zigher@...>
 

Have you looked at
https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/classes/kernel-fitimage.bbclass?
I cannot see that there is an option for determining the compression.
It appears as if it looks specifically for bin-file. I am no expert
regarding fitimage format so I cannot say what the best solution is.

/Måns

Den ons 5 juni 2019 kl 11:24 skrev Pierluigi Greto <pierluigi.greto@bisdn.de>:


Hello everyone,

I'm building an fitImage and I would like to set the kernel compression
type. Yocto is automatically creating the linux.bin but I cannot find
any variable to specify the kernel compression type. I would like to
have a gzip compressed kernel. Is possible to specify the compression
type by using a variable? If not, there are other ways?

Thank you,
Pierluigi

--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


fitImage kernel compression type

Pierluigi Greto
 

Hello everyone,

I'm building an fitImage and I would like to set the kernel compression type. Yocto is automatically creating the linux.bin but I cannot find any variable to specify the kernel compression type. I would like to have a gzip compressed kernel. Is possible to specify the compression type by using a variable? If not, there are other ways?

Thank you,
Pierluigi


[multilib] No Manifest file generated from: lib32-alsa-lib

Måns Zigher <mans.zigher@...>
 

Hi,

I am trying to build an SDK where I have multilib enabled in my
local.conf but I am encountering this error message

WARNING: strix-sdk-1.0-r0 do_populate_sdk: Manifest
/workdir/builds/imx8mm/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm
not found in mimx8mm aarch64-mx8mm armv7at2hf-neon armv7ahf-neon
armv7at2hf-vfp armv7ahf-vfp armv6thf-vfp armv6hf-vfp armv5tehf-vfp
armv5ehf-vfp armv5thf-vfp armv5hf-vfp allarch x86_64_x86_64-nativesdk
(variant 'lib32')?
ERROR: strix-sdk-1.0-r0 do_populate_sdk: No manifest generated from:
lib32-alsa-lib in
virtual:multilib:lib32:/workdir/layers/poky/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb
ERROR: strix-sdk-1.0-r0 do_populate_sdk: Function failed: do_populate_sdk

I am currently using poky sumo could not see that anything have
changed in alsa-lib except bumping it to 1.1.6 in thud. I have tried
go through the code in both

./poky/meta/lib/oe/package_manager.py

and

./poky/meta/lib/oe/sstatesig.py

to see if I could understand why there is no manifest file created for
lib32-alsa-lib but without any luck. What task should I run to create
the Manifest file? Any other pointers to where I should look to
understand this issue is appreciated.

BR
Måns Zigher


-vfp arm tuning missing in builds and WORKDIR

Danny
 

Currently the SDK that is being built, builds successfully but does not contain the vfp arm tuning part included. Overriding the “TARGET_FPU” variable in the local.conf and setting it to “vfp-neon”, does reflect in the Build Configuration section, but that still has no difference in the SDK being built. The TARGET_FPU by default is been set to “hard”. This was possible in the earlier versions on Yocto though. Setting the CFLAGS in the machine configuration to -mfpu=vfp-neon also has taken no effect.


Would it have something to do with GCC itself?

 

In other words, the SDK currently being built is “poky-glibc-x86_64-my-meta-toolchain-cortexa8hf-neon-toolchain-2.5.sh” but what is desired is “poky-glibc-x86_64-my-meta-toolchain-cortexa8hf-vfp-neon-toolchain-2.5.sh

 

Below is my Build Config,

Build Configuration:

BB_VERSION           = "1.37.0"

BUILD_SYS            = "x86_64-linux"

NATIVELSBSTRING      = "universal-4.8"

TARGET_SYS           = "arm-poky-linux-gnueabi"

MACHINE              = "arm-cortex-a8"

DISTRO               = "poky"

DISTRO_VERSION       = "2.5"

TUNE_FEATURES        = "arm armv7a vfp neon callconvention-hard cortexa8"

TARGET_FPU           = "hard"

meta-bsp-ti       

meta                

meta-poky           

meta-yocto-bsp      

meta-my-common     

meta-oe              = "<unknown>:<unknown>"

 

Did something change in the Sumo version of Yocto and Is there any other way of achieving this?

Any leads in achieving and helping better understand is appreciated.


Thanks!

 

Best Regards,
Danny


[meta-gplv2][PATCH] elfutils: ignore new error from gcc-9

Martin Jansa
 

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
recipes-devtools/elfutils/elfutils_0.148.bb | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/recipes-devtools/elfutils/elfutils_0.148.bb b/recipes-devtools/elfutils/elfutils_0.148.bb
index a03b74e..1f07a28 100644
--- a/recipes-devtools/elfutils/elfutils_0.148.bb
+++ b/recipes-devtools/elfutils/elfutils_0.148.bb
@@ -57,6 +57,10 @@ SRC_URI += "\
"
inherit autotools gettext

+# There is a fix in 0.175 version (https://sourceware.org/bugzilla/show_bug.cgi?id=23884)
+# but 0.175 has different license, so to be safe don't backport the fix, just ignore the issue
+CFLAGS += "-Wno-error=missing-attributes"
+
EXTRA_OECONF = "--program-prefix=eu- --without-lzma"
EXTRA_OECONF_append_class-native = " --without-bzlib"
EXTRA_OECONF_append_libc-uclibc = " --enable-uclibc"
--
2.17.1

7061 - 7080 of 52565