yocto@lists.yoctoproject.org

How to set PACKAGE_EXTRA_ARCHS

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

#45502

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

#45501

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

#45500

-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

#45499

Hi,

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

https://layers.openembedded.org/layerindex/recipe/4796/

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

#45498

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

#45497

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

#45496

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

#45495

Pushed, thanks.

Ross

Show quoted text

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

#45494

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

signature.asc