Date   

Re: glibc -fstack-protector-strong

Khem Raj
 

On 10/14/21 7:35 PM, Paul Eggleton wrote:
Hi folks
I'm looking at how -fstack-protector-strong might be enabled in the glibc
recipe. It looks like it should already be enabled by default via
--enable-stack-protector=strong in EXTRA_OECONF, however looking at the
compile logs it is passing -fno-stack-protector instead. Examining the
configure log:
checking for -fstack-protector... (cached) no
checking for -fstack-protector-strong... (cached) no
checking for -fstack-protector-all... (cached) no
This in turn comes from libc_cv_ssp_strong=no in CACHED_CONFIGUREVARS in
glibc.inc. Searching back through the git history I can't find much by way of
explanation as to why the stack protector options are disabled. Setting
libc_cv_ssp_strong=yes however results in the following:
| x86_64-poky-linux-gcc -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse --sysroot=/media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/recipe-sysroot -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,relro,-z,now -fuse-ld=bfd -nostdlib -nostartfiles -r -o /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/libc_pic.os \
| -Wl,-d -Wl,--whole-archive /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/libc_pic.a -o /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/libc_pic.os
| x86_64-poky-linux-gcc -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse --sysroot=/media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/recipe-sysroot -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,relro,-z,now -fuse-ld=bfd -nostdlib -nostartfiles -r -o /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/elf/librtld.map.o \
| '-Wl,-(' /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/elf/dl-allobjs.os /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/libc_pic.a -lgcc '-Wl,-)' -Wl,-Map,/media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/elf/librtld.mapT
| /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.3.0/ld.bfd: /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/libc_pic.a(libc_fatal.os): in function `__GI___libc_fatal':
| /usr/src/debug/glibc/2.31+gitAUTOINC+4f0a61f753-r0/git/libio/../sysdeps/posix/libc_fatal.c:161: multiple definition of `__GI___libc_fatal'; /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/elf/dl-allobjs.os:/usr/src/debug/glibc/2.31+gitAUTOINC+4f0a61f753-r0/git/elf/dl-minimal.c:188: first defined here
| /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.3.0/ld.bfd: /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/libc_pic.a(libc_fatal.os): in function `__GI___libc_fatal':
| /usr/src/debug/glibc/2.31+gitAUTOINC+4f0a61f753-r0/git/libio/../sysdeps/posix/libc_fatal.c:161: multiple definition of `__libc_fatal'; /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/elf/dl-allobjs.os:/usr/src/debug/glibc/2.31+gitAUTOINC+4f0a61f753-r0/git/elf/dl-minimal.c:188: first defined here
| collect2: error: ld returned 1 exit status
| make[2]: *** [Makefile:499: /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/elf/librtld.map] Error 1
| make[2]: *** Waiting for unfinished jobs....
| make[2]: Leaving directory '/media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/git/elf'
| make[1]: *** [Makefile:490: elf/subdir_lib] Error 2
| make[1]: Leaving directory '/media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/git'
| make: *** [Makefile:9: all] Error 2
| ERROR: oe_runmake failed
This is not an area I have looked much into before; does anyone have any insights?
This was enabling ssp support in glibc not only for other programs but also for rest of glibc components during compile and that resulted in duplicate symbols, IIRC thats why we disabled it, the error you are seeing looks that we still have that problem lurking around. Unfortunately I dont have a solution handy to offer

Thanks
Paul


glibc -fstack-protector-strong

Paul Eggleton
 

Hi folks

I'm looking at how -fstack-protector-strong might be enabled in the glibc
recipe. It looks like it should already be enabled by default via
--enable-stack-protector=strong in EXTRA_OECONF, however looking at the
compile logs it is passing -fno-stack-protector instead. Examining the
configure log:

checking for -fstack-protector... (cached) no
checking for -fstack-protector-strong... (cached) no
checking for -fstack-protector-all... (cached) no

This in turn comes from libc_cv_ssp_strong=no in CACHED_CONFIGUREVARS in
glibc.inc. Searching back through the git history I can't find much by way of
explanation as to why the stack protector options are disabled. Setting
libc_cv_ssp_strong=yes however results in the following:

| x86_64-poky-linux-gcc -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse --sysroot=/media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/recipe-sysroot -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,relro,-z,now -fuse-ld=bfd -nostdlib -nostartfiles -r -o /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/libc_pic.os \
| -Wl,-d -Wl,--whole-archive /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/libc_pic.a -o /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/libc_pic.os
| x86_64-poky-linux-gcc -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse --sysroot=/media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/recipe-sysroot -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,relro,-z,now -fuse-ld=bfd -nostdlib -nostartfiles -r -o /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/elf/librtld.map.o \
| '-Wl,-(' /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/elf/dl-allobjs.os /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/libc_pic.a -lgcc '-Wl,-)' -Wl,-Map,/media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/elf/librtld.mapT
| /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.3.0/ld.bfd: /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/libc_pic.a(libc_fatal.os): in function `__GI___libc_fatal':
| /usr/src/debug/glibc/2.31+gitAUTOINC+4f0a61f753-r0/git/libio/../sysdeps/posix/libc_fatal.c:161: multiple definition of `__GI___libc_fatal'; /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/elf/dl-allobjs.os:/usr/src/debug/glibc/2.31+gitAUTOINC+4f0a61f753-r0/git/elf/dl-minimal.c:188: first defined here
| /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.3.0/ld.bfd: /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/libc_pic.a(libc_fatal.os): in function `__GI___libc_fatal':
| /usr/src/debug/glibc/2.31+gitAUTOINC+4f0a61f753-r0/git/libio/../sysdeps/posix/libc_fatal.c:161: multiple definition of `__libc_fatal'; /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/elf/dl-allobjs.os:/usr/src/debug/glibc/2.31+gitAUTOINC+4f0a61f753-r0/git/elf/dl-minimal.c:188: first defined here
| collect2: error: ld returned 1 exit status
| make[2]: *** [Makefile:499: /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/elf/librtld.map] Error 1
| make[2]: *** Waiting for unfinished jobs....
| make[2]: Leaving directory '/media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/git/elf'
| make[1]: *** [Makefile:490: elf/subdir_lib] Error 2
| make[1]: Leaving directory '/media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/git'
| make: *** [Makefile:9: all] Error 2
| ERROR: oe_runmake failed

This is not an area I have looked much into before; does anyone have any insights?

Thanks
Paul


Re: docker fragment missing conntrack and netfilter entries? #meta-virtualization

Bruce Ashfield
 

On Thu, Oct 14, 2021 at 12:23 PM <crawford.benjamin15@gmail.com> wrote:

Hi,

I have just completed a bringup of Poky on the ODROID N2+ platform, but noticed that Docker failed to start, complaining that it could not load the "nf_conntrack_netlink" module.
After checking docker.cfg, I noticed that a few configuration options I expected were missing.

Shouldn't the following be added: (?)

CONFIG_NETFILTER_NETLINK=m
CONFIG_NT_CT_NETLINK=m

CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
FYI: you want the meta-virtualization mailing list, not the main yocto
one for questions like this.

There's a balancing act with the fragments: they are as
non-overlapping as possible, they often support a wide range of kernel
versions and kernel providers, so there are sometimes more, or less
options than you'd expect in a fragment.

In particular the fragments in meta-virtualization are changing right
now, and are being unified in the kernel-cache repository (that allows
the duplicated options to be rationalized).

So depending on which docker.cfg you are looking at, you'd either send
a patch to the linux-yocto mailing list, or the meta-virtualization
list.

In particular, the netfilter fragment is what is expected to provide
many of the needed options, and that's what has been happening with
the out of box docker, lxc, podman, k8s, etc, configurations tested in
meta-virt. The docker.scc fragment will start pulling that in
automatically as part of the de-duplication effort I hinted at above.

But there's no harm in sending a patch, I'll figure out how/where it
applies as I go through those efforts.

Cheers,

Bruce







Thanks,
Ben




--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


[PATCH yocto-autobuilder-helper] scripts/collect-results: publish everything in tmp/log/oeqa/

Alexander Kanavin
 

From: Alexander Kanavin <alex@linutronix.de>

In addition to the testresult json, testimage class now also
provides the testimage task log and qemu console output log
which can be useful for debugging test failures or
even checking qemu test runs when failures did not happen.

Rather than duplicate specific file/folder names, let's copy all
that is available, and define what is published in the testimage
class itself (with appropriate folder structure if/when needed).
At the moment there's just three files, and they are copied into
folders named after image names, so there's no clutter or risk
of mixing them up with unrelated logs.

[YOCTO #14518]

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
scripts/collect-results | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/scripts/collect-results b/scripts/collect-results
index 93834d6..7caa177 100755
--- a/scripts/collect-results
+++ b/scripts/collect-results
@@ -3,11 +3,9 @@ WORKDIR=$1
DEST=$2
target=$3

-RESFILE=$WORKDIR/tmp/log/oeqa/testresults.json
-
-if [ -e $RESFILE ]; then
- mkdir -p $DEST/$target
- cp $WORKDIR/tmp/log/oeqa/testresults.json $DEST/$target/
+mkdir -p $DEST
+if [ -e $WORKDIR/tmp/log/oeqa/ ]; then
+ cp -Lrf $WORKDIR/tmp/log/oeqa/ $DEST/$target
fi

if [ -e $WORKDIR/buildhistory ]; then
--
2.31.1


Re: docker fragment missing conntrack and netfilter entries? #meta-virtualization

Khem Raj
 

On 10/14/21 9:23 AM, crawford.benjamin15@gmail.com wrote:
Hi,
I have just completed a bringup of Poky on the ODROID N2+ platform, but noticed that Docker failed to start, complaining that it could not load the "nf_conntrack_netlink" module.
After checking docker.cfg, I noticed that a few configuration options I expected were missing.
Shouldn't the following be added: (?)
|CONFIG_NETFILTER_NETLINK=m|
|CONFIG_NT_CT_NETLINK=m|
|CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
seems fine. Please send a patch for enhancing it via docker.cfg

Thanks,
Ben|


Re: [PATCH yocto-autobuilder-helper] scripts/collect-results: publish everything in tmp/log/oeqa/

Alexander Kanavin
 

On Thu, 14 Oct 2021 at 18:08, Richard Purdie <richard.purdie@...> wrote:
Since that build directory contains symlinks, we may need something like cp -L
here? I didn't test but I think we might run into an issue?

That's right, -L is needed.

Alex


docker fragment missing conntrack and netfilter entries? #meta-virtualization

crawford.benjamin15@...
 

Hi,

I have just completed a bringup of Poky on the ODROID N2+ platform, but noticed that Docker failed to start, complaining that it could not load the "nf_conntrack_netlink" module.
After checking docker.cfg, I noticed that a few configuration options I expected were missing.

Shouldn't the following be added: (?)

CONFIG_NETFILTER_NETLINK=m
CONFIG_NT_CT_NETLINK=m

CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m

Thanks,
Ben


Re: [PATCH yocto-autobuilder-helper] scripts/collect-results: publish everything in tmp/log/oeqa/

Richard Purdie
 

On Wed, 2021-10-13 at 18:18 +0200, Alexander Kanavin wrote:
From: Alexander Kanavin <alex@linutronix.de>

In addition to the testresult json, testimage class now also
provides the testimage task log and qemu console output log
which can be useful for debugging test failures or
even checking qemu test runs when failures did not happen.

Rather than duplicate specific file/folder names, let's copy all
that is available, and define what is published in the testimage
class itself (with appropriate folder structure if/when needed).
At the moment there's just three files, and they are copied into
folders named after image names, so there's no clutter or risk
of mixing them up with unrelated logs.

[YOCTO #14518]

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
scripts/collect-results | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/scripts/collect-results b/scripts/collect-results
index 93834d6..3663330 100755
--- a/scripts/collect-results
+++ b/scripts/collect-results
@@ -3,11 +3,9 @@ WORKDIR=$1
DEST=$2
target=$3

-RESFILE=$WORKDIR/tmp/log/oeqa/testresults.json
-
-if [ -e $RESFILE ]; then
- mkdir -p $DEST/$target
- cp $WORKDIR/tmp/log/oeqa/testresults.json $DEST/$target/
+mkdir -p $DEST
+if [ -e $WORKDIR/tmp/log/oeqa/ ]; then
+ cp -rf $WORKDIR/tmp/log/oeqa/ $DEST/$target
fi
Since that build directory contains symlinks, we may need something like cp -L
here? I didn't test but I think we might run into an issue?

Cheers,

Richard


Minutes: Yocto Project Weekly Triage Meeting 10/14/2021

Kiran Surendran
 

Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage

Attendees: Steve, Randy, Bruce, Ross, Richard, Alexandre, Tim, Joshua, Kiran

ARs: NONE


Notes: NONE


Medium+ 3.4 Unassigned Enhancements/Bugs: 68 (No change)

Medium+ 3.5 Unassigned Enhancements/Bugs: 12 (No change)

Medium+ 3.99 Unassigned Enhancements/Bugs: 39 (No change)

AB Bugs:  65 (Last week 64)


[PATCH yocto-autobuilder-helper] config.json: build FVP-Base instead of N1SDP

Ross Burton <ross@...>
 

FVP-Base is a better supported and more generally useful machine than N1S=
DP.

Signed-off-by: Ross Burton <ross.burton@arm.com>
---
config.json | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/config.json b/config.json
index 0fe1f1a..dd890fe 100644
--- a/config.json
+++ b/config.json
@@ -324,11 +324,13 @@
"${BUILDDIR}/../meta-arm/meta-arm-bsp"
],
"step1": {
- "MACHINE": "n1sdp",
+ "shortname": "Build for fvp-base",
+ "MACHINE": "fvp-base",
"BBTARGETS": "core-image-minimal core-image-sato core-im=
age-sato:do_populate_sdk",
"SANITYTARGETS" : "core-image-sato:do_testsdk"
},
"step2": {
+ "shortname": "Build for juno",
"MACHINE": "juno",
"BBTARGETS": "core-image-minimal core-image-sato core-im=
age-sato:do_populate_sdk",
"SANITYTARGETS" : "core-image-sato:do_testsdk"
--=20
2.25.1


Re: #zeus meta-intel #zeus

Monsees, Steven C (US)
 

Thank you.

I will most likely look into creating a dunfell based build this weekend...
My current system is zeus based, centos, still using sysvinit on startup...

Did run using clang 9.0 ?

I appreciate your time and trouble,
Steve

-----Original Message-----
From: Mittal, Anuj <anuj.mittal@intel.com>
Sent: Wednesday, October 13, 2021 9:28 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>; yocto@lists.yoctoproject.org
Subject: Re: [yocto] #zeus meta-intel

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros. For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.


There are no patches needed other than what is already in oe-core/meta- intel/meta-clang. I tried building zeus on Ubuntu 16.04 and didn't see any problem.

zeus is no longer maintained or supported so I'd suggest checking a newer release or experimenting without using buildtools to see if that is exposing this problem. It does look like things are not being compiled properly or perhaps opencl-clang-native is linking to incorrect LLVM ...

Thanks,

Anuj

On Wed, 2021-10-13 at 16:53 +0000, Monsees, Steven C (US) wrote:

Anything ?, I have yet to resolve this.

-----Original Message-----
From: Monsees, Steven C (US)
Sent: Wednesday, October 13, 2021 9:03 AM
To: 'Mittal, Anuj' <anuj.mittal@intel.com>;
'yocto@lists.yoctoproject.org' <yocto@lists.yoctoproject.org>
Subject: RE: [yocto] #zeus meta-intel


Are there any patches required for these components (igc, opencl-
clang, and intel-compute-runtime) ?

-----Original Message-----
From: Monsees, Steven C (US)
Sent: Wednesday, October 13, 2021 7:13 AM
To: 'Mittal, Anuj' <anuj.mittal@intel.com>;
yocto@lists.yoctoproject.org
Subject: RE: [yocto] #zeus meta-intel


Anuj:

I rebuilt the entire image (but did not delete the state_cache)...
I am building meta-clang (zeus based, I believe it is 9.0.1).

Steve

-----Original Message-----
From: Mittal, Anuj <anuj.mittal@intel.com>
Sent: Tuesday, October 12, 2021 10:10 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>;
yocto@lists.yoctoproject.org
Subject: Re: [yocto] #zeus meta-intel

External Email Alert

This email has been sent from an account outside of the BAE Systems
network.

Please treat the email with caution, especially if you are requested
to click on a link, decrypt/open an attachment, or enable macros.
For further information on how to spot phishing, access “Cybersecurity
OneSpace Page” and report phishing by clicking the button “Report
Phishing” on the Outlook toolbar.


Did you build everything with this compiler from start? Is opencl-
clang building with the right LLVM lib from meta-clang?

Thanks,

Anuj

On Tue, 2021-10-12 at 17:15 +0000, Monsees, Steven C (US) wrote:

Anuj:

I picked up the tarball for for the baseline dunfell tools platform
to update host tools...

I am seeing it compile cleaner but for one issue causng ld to fail:

/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:1331:
undefined reference to `vtable for
llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>,
std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >'

Isn't LLVM brought in along with clang under meta-clang ?

Is there a missing build dependency ?

Thanks,
Steve

Build excerpt showing multiple " undefined reference to `vtable "
errors...

/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >::~opt()':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:1331:
undefined reference to `vtable for
llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>,
std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::OptionValue<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >::OptionValue()':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:601:
undefined reference to `vtable for
llvm::cl::OptionValue<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >
::opt<llvm::cl::FormattingFlags, llvm::cl::desc,
llvm::cl::desc const&, llvm::cl::initializer<char [2]> const&)':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:1407:
undefined reference to `vtable for
llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>,
std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >
::parser(llvm::cl::Option&)':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:1072:
undefined reference to `vtable for
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >::~opt()':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:1331:
undefined reference to `vtable for
llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>,
std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::OptionValue<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >::OptionValue()':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:601:
undefined reference to `vtable for
llvm::cl::OptionValue<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >::opt<char [9],
llvm::cl::desc>(char const (&) [9], llvm::cl::desc const&)':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:1407:
undefined reference to `vtable for
llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>,
std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >
::parser(llvm::cl::Option&)':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:1072:
undefined reference to `vtable for
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >'
collect2: error: ld returned 1 exit status

-----Original Message-----
From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On
Behalf Of Anuj Mittal
Sent: Tuesday, October 12, 2021 10:43 AM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>;
yocto@lists.yoctoproject.org
Subject: Re: [yocto] #zeus meta-intel

External Email Alert

network.

Please treat the email with caution, especially if you are requested
to click on a link, decrypt/open an attachment, or enable macros.
For
further information on how to spot phishing, access “Cybersecurity
OneSpace Page” and report phishing by clicking the button “Report
Phishing” on the Outlook toolbar.


On Tue, 2021-10-12 at 12:43 +0000, Monsees, Steven C (US) wrote:
g++: error: unrecognized command line option ‘-std=c++14’
It looks like the gcc version is too old on your host for this to
work.

Thanks,

Anuj


[PATCH v2 1/1] sssd: re-package to fix QA issues

kai
 

From: Kai Kang <kai.kang@windriver.com>

It packages all file in ${libdir} to package sssd, including the .so
symlink files. Then it causes QA issues:

| ERROR: QA Issue: sssd rdepends on dbus-dev [dev-deps]
| ERROR: QA Issue: sssd rdepends on ding-libs-dev [dev-deps]

So re-package sssd then the .so symlink files and .pc files are packaged
to sssd-dev which should be.

File ${libdir}/libsss_sudo.so is not a symlink file but packaged to
sssd-dev too. Then causes another QA issue:

| ERROR: sssd-2.5.2-r0 do_package_qa: QA Issue:
-dev package sssd-dev contains non-symlink .so '/usr/lib/libsss_sudo.so' [dev-elf]

So create a new sub-package libsss-sudo to package file libsss_sudo.so
and make sssd rdepends on it.

Signed-off-by: Kai Kang <kai.kang@windriver.com>
---
recipes-security/sssd/sssd_2.5.2.bb | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/recipes-security/sssd/sssd_2.5.2.bb b/recipes-security/sssd/sssd_2.5.2.bb
index 76d6e03..ed8af5e 100644
--- a/recipes-security/sssd/sssd_2.5.2.bb
+++ b/recipes-security/sssd/sssd_2.5.2.bb
@@ -125,10 +125,14 @@ SYSTEMD_SERVICE:${PN} = " \
"
SYSTEMD_AUTO_ENABLE = "disable"

-FILES:${PN} += "${libdir} ${datadir} ${base_libdir}/security/pam_sss*.so"
-FILES:${PN}-dev = " ${includedir}/* ${libdir}/*la ${libdir}/*/*la"
+PACKAGES =+ "libsss-sudo"
+ALLOW_EMPTY:libsss-sudo = "1"

-# The package contains symlinks that trip up insane
-INSANE_SKIP:${PN} = "dev-so"
+FILES:${PN} += "${base_libdir}/security/pam_sss*.so \
+ ${datadir}/dbus-1/system-services/*.service \
+ ${libdir}/krb5/* \
+ ${libdir}/ldb/* \
+ "
+FILES:libsss-sudo = "${libdir}/libsss_sudo.so"

-RDEPENDS:${PN} = "bind bind-utils dbus libldb libpam"
+RDEPENDS:${PN} = "bind bind-utils dbus libldb libpam libsss-sudo"
--
2.17.1


[PATCH v2 0/1] sssd: re-package to fix QA issues

kai
 

From: Kai Kang <kai.kang@windriver.com>

v2:
* replace _ with - new sub-package name
* allow empty for new sub-package that it is enabled/disabled by a
package config

Kai Kang (1):
sssd: re-package to fix QA issues

recipes-security/sssd/sssd_2.5.2.bb | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)

--
2.17.1


[psplash][PATCH v2] Add configure options to disable progress bar

Pavel Zhukov
 

Progress bar can overlap with products logos, added
--disable-progress-bar configure option to disable progress
bar completely without patching the code.
Default behaviour is to show progress bar

Signed-off-by: Pavel Zhukov <pavel.zhukov@huawei.com>
---
configure.ac | 8 ++++++++
psplash-config.h | 5 +++++
psplash.c | 14 ++++++++++----
3 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 2d836a1..2a7da91 100644
--- a/configure.ac
+++ b/configure.ac
@@ -37,6 +37,14 @@ AS_IF([test x$disable_startup_msg =3D xtrue], [
EXTRA_GCC_FLAGS=3D"$EXTRA_GCC_FLAGS -DPSPLASH_DISABLE_STARTUP_MSG"
])
=20
+AC_ARG_ENABLE([progress-bar],
+ AS_HELP_STRING([--disable-progress-bar], [Disable progress bar]),
+ [disable_progress_bar=3Dtrue],
+ [disable_progress_bar=3Dfalse])
+AS_IF([test x$disable_progress_bar =3D xtrue], [
+ EXTRA_GCC_FLAGS=3D"$EXTRA_GCC_FLAGS -DPSPLASH_DISABLE_PROGRESS_BAR"
+])
+
AC_ARG_ENABLE([img-fullscreen],
AS_HELP_STRING([--enable-img-fullscreen], [Enable the logo image in =
fullscreen mode)]),
[img_fullscreen=3Dtrue],
diff --git a/psplash-config.h b/psplash-config.h
index 0ba8440..eb90ef3 100644
--- a/psplash-config.h
+++ b/psplash-config.h
@@ -21,6 +21,11 @@
#define PSPLASH_IMG_FULLSCREEN 0
#endif
=20
+/* Bool indicated if the progress bar should be disabled */
+#ifndef PSPLASH_DISABLE_PROGRESS_BAR
+#define PSPLASH_SHOW_PROGRESS_BAR 1
+#endif
+
/* Position of the image split from top edge, numerator of fraction */
#define PSPLASH_IMG_SPLIT_NUMERATOR 5
=20
diff --git a/psplash.c b/psplash.c
index 1a56629..ee1af6b 100644
--- a/psplash.c
+++ b/psplash.c
@@ -61,6 +61,7 @@ psplash_draw_msg (PSplashFB *fb, const char *msg)
msg);
}
=20
+#ifdef PSPLASH_SHOW_PROGRESS_BAR
void
psplash_draw_progress (PSplashFB *fb, int value)
{
@@ -95,6 +96,7 @@ psplash_draw_progress (PSplashFB *fb, int value)
DBG("value: %i, width: %i, barwidth :%i\n", value,=20
width, barwidth);
}
+#endif /* PSPLASH_SHOW_PROGRESS_BAR */
=20
static int=20
parse_command (PSplashFB *fb, char *string)
@@ -108,20 +110,22 @@ parse_command (PSplashFB *fb, char *string)
=20
command =3D strtok(string," ");
=20
- if (!strcmp(command,"PROGRESS"))=20
+ if (!strcmp(command,"MSG"))
{
char *arg =3D strtok(NULL, "\0");
=20
if (arg)
- psplash_draw_progress (fb, atoi(arg));
+ psplash_draw_msg (fb, arg);
}=20
- else if (!strcmp(command,"MSG"))=20
+ #ifdef PSPLASH_SHOW_PROGRESS_BAR
+ else if (!strcmp(command,"PROGRESS"))
{
char *arg =3D strtok(NULL, "\0");
=20
if (arg)
- psplash_draw_msg (fb, arg);
+ psplash_draw_progress (fb, atoi(arg));
}=20
+#endif
else if (!strcmp(command,"QUIT"))=20
{
return 1;
@@ -311,6 +315,7 @@ main (int argc, char** argv)
POKY_IMG_ROWSTRIDE,
POKY_IMG_RLE_PIXEL_DATA);
=20
+#ifdef PSPLASH_SHOW_PROGRESS_BAR
/* Draw progress bar border */
psplash_fb_draw_image (fb,=20
(fb->width - BAR_IMG_WIDTH)/2,=20
@@ -322,6 +327,7 @@ main (int argc, char** argv)
BAR_IMG_RLE_PIXEL_DATA);
=20
psplash_draw_progress (fb, 0);
+#endif
=20
#ifdef PSPLASH_STARTUP_MSG
psplash_draw_msg (fb, PSPLASH_STARTUP_MSG);
--=20
2.31.1


[psplash][PATCH] Add configure options to disable progress bar

Pavel Zhukov
 

From: Pavel Zhukov <pavel.zhukov@huawei.com>

Progress bar can overlap with products logos, added
--disable-progress-bar configure option to disable progress
bar completely without patching the code.
Default behaviour is to show progress bar

Signed-off-by: Pavel Zhukov <pavel.zhukov@huawei.com>
---
configure.ac | 8 ++++++++
psplash-config.h | 5 +++++
psplash.c | 14 ++++++++++----
3 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 2d836a1..2a7da91 100644
--- a/configure.ac
+++ b/configure.ac
@@ -37,6 +37,14 @@ AS_IF([test x$disable_startup_msg =3D xtrue], [
EXTRA_GCC_FLAGS=3D"$EXTRA_GCC_FLAGS -DPSPLASH_DISABLE_STARTUP_MSG"
])
=20
+AC_ARG_ENABLE([progress-bar],
+ AS_HELP_STRING([--disable-progress-bar], [Disable progress bar]),
+ [disable_progress_bar=3Dtrue],
+ [disable_progress_bar=3Dfalse])
+AS_IF([test x$disable_progress_bar =3D xtrue], [
+ EXTRA_GCC_FLAGS=3D"$EXTRA_GCC_FLAGS -DPSPLASH_DISABLE_PROGRESS_BAR"
+])
+
AC_ARG_ENABLE([img-fullscreen],
AS_HELP_STRING([--enable-img-fullscreen], [Enable the logo image in =
fullscreen mode)]),
[img_fullscreen=3Dtrue],
diff --git a/psplash-config.h b/psplash-config.h
index 0ba8440..eb90ef3 100644
--- a/psplash-config.h
+++ b/psplash-config.h
@@ -21,6 +21,11 @@
#define PSPLASH_IMG_FULLSCREEN 0
#endif
=20
+/* Bool indicated if the progress bar should be disabled */
+#ifndef PSPLASH_DISABLE_PROGRESS_BAR
+#define PSPLASH_SHOW_PROGRESS_BAR 1
+#endif
+
/* Position of the image split from top edge, numerator of fraction */
#define PSPLASH_IMG_SPLIT_NUMERATOR 5
=20
diff --git a/psplash.c b/psplash.c
index 1a56629..ee1af6b 100644
--- a/psplash.c
+++ b/psplash.c
@@ -61,6 +61,7 @@ psplash_draw_msg (PSplashFB *fb, const char *msg)
msg);
}
=20
+#ifdef PSPLASH_SHOW_PROGRESS_BAR
void
psplash_draw_progress (PSplashFB *fb, int value)
{
@@ -95,6 +96,7 @@ psplash_draw_progress (PSplashFB *fb, int value)
DBG("value: %i, width: %i, barwidth :%i\n", value,=20
width, barwidth);
}
+#endif /* PSPLASH_SHOW_PROGRESS_BAR */
=20
static int=20
parse_command (PSplashFB *fb, char *string)
@@ -108,20 +110,22 @@ parse_command (PSplashFB *fb, char *string)
=20
command =3D strtok(string," ");
=20
- if (!strcmp(command,"PROGRESS"))=20
+ if (!strcmp(command,"MSG"))
{
char *arg =3D strtok(NULL, "\0");
=20
if (arg)
- psplash_draw_progress (fb, atoi(arg));
+ psplash_draw_msg (fb, arg);
}=20
- else if (!strcmp(command,"MSG"))=20
+ #ifdef PSPLASH_SHOW_PROGRESS_BAR
+ else if (!strcmp(command,"PROGRESS"))
{
char *arg =3D strtok(NULL, "\0");
=20
if (arg)
- psplash_draw_msg (fb, arg);
+ psplash_draw_progress (fb, atoi(arg));
}=20
+#endif
else if (!strcmp(command,"QUIT"))=20
{
return 1;
@@ -311,6 +315,7 @@ main (int argc, char** argv)
POKY_IMG_ROWSTRIDE,
POKY_IMG_RLE_PIXEL_DATA);
=20
+#ifdef PSPLASH_SHOW_PROGRESS_BAR
/* Draw progress bar border */
psplash_fb_draw_image (fb,=20
(fb->width - BAR_IMG_WIDTH)/2,=20
@@ -322,6 +327,7 @@ main (int argc, char** argv)
BAR_IMG_RLE_PIXEL_DATA);
=20
psplash_draw_progress (fb, 0);
+#endif
=20
#ifdef PSPLASH_STARTUP_MSG
psplash_draw_msg (fb, PSPLASH_STARTUP_MSG);
--=20
2.31.1


Re: [meta-security][PATCH] sssd: re-package to fix QA issues

kai
 

On 10/14/21 4:08 AM, akuster808 wrote:
Hi armin,
changing the 'libsss_sudo' to 'libsss-sudo' fixes the errors.

I can do this locally or you can send a v2.
v2 will be sent. Thanks.

Kai


- armin

On 10/13/21 12:57 PM, Armin Kuster via lists.yoctoproject.org wrote:
On 10/13/21 1:49 AM, kai wrote:
From: Kai Kang <kai.kang@windriver.com>

It packages all file in ${libdir} to package sssd, including the .so
symlink files. Then it causes QA issues:

| ERROR: QA Issue: sssd rdepends on dbus-dev [dev-deps]
| ERROR: QA Issue: sssd rdepends on ding-libs-dev [dev-deps]

So re-package sssd then the .so symlink files and .pc files are packaged
to sssd-dev which should be.

File ${libdir}/libsss_sudo.so is not a symlink file but packaged to
sssd-dev too. Then causes another QA issue:

| ERROR: sssd-2.5.2-r0 do_package_qa: QA Issue:
-dev package sssd-dev contains non-symlink .so '/usr/lib/libsss_sudo.so' [dev-elf]
When building for ipk and deb I am seeing these errors.

IPK:
ERROR: sssd-2.5.2-r0 do_package_write_ipk: Fatal errors occurred in
subprocesses:
Command
'PATH="/home/akuster/oss/clean/poky/build/tmp/sysroots-uninative/x86_64-linux/usr/bin:/home/akuster/oss/clean/poky/scripts:/home/akuster/oss/clean/poky/build/tmp/work/core2-32-poky-linux/sssd/2.5.2-r0/recipe-sysroot-native/usr/bin/i686-poky-linux:/home/akuster/oss/clean/poky/build/tmp/work/core2-32-poky-linux/sssd/2.5.2-r0/recipe-sysroot/usr/bin/crossscripts:/home/akuster/oss/clean/poky/build/tmp/work/core2-32-poky-linux/sssd/2.5.2-r0/recipe-sysroot-native/usr/sbin:/home/akuster/oss/clean/poky/build/tmp/work/core2-32-poky-linux/sssd/2.5.2-r0/recipe-sysroot-native/usr/bin:/home/akuster/oss/clean/poky/build/tmp/work/core2-32-poky-linux/sssd/2.5.2-r0/recipe-sysroot-native/sbin:/home/akuster/oss/clean/poky/build/tmp/work/core2-32-poky-linux/sssd/2.5.2-r0/recipe-sysroot-native/bin:/home/akuster/oss/clean/poky/bitbake/bin:/home/akuster/oss/clean/poky/build/tmp/hosttools"
opkg-build -Z xz -a "--memlimit=50% --threads=16" libsss_sudo
/home/akuster/oss/clean/poky/build/tmp/work/core2-32-poky-linux/sssd/2.5.2-r0/deploy-ipks/core2-32'
returned non-zero exit status 1.
Subprocess output:libsss_sudo
*** Error: Package name libsss_sudo contains illegal characters, (other
than [a-z0-9.+-])

opkg-build: Please fix the above errors and try again.

ERROR: Logfile of failure stored in:
/home/akuster/oss/clean/poky/build/tmp/work/core2-32-poky-linux/sssd/2.5.2-r0/temp/log.do_package_write_ipk.2960686
ERROR: Task
(/home/akuster/oss/maint/meta-security/recipes-security/sssd/sssd_2.5.2.bb:do_package_write_ipk)
failed with exit code '1'

DEB:

ERROR: sssd-2.5.2-r0 do_package_write_deb: Fatal errors occurred in
subprocesses:
Command
'PATH="/home/akuster/oss/clean/poky/build/tmp/sysroots-uninative/x86_64-linux/usr/bin:/home/akuster/oss/clean/poky/scripts:/home/akuster/oss/clean/poky/build/tmp/work/core2-32-poky-linux/sssd/2.5.2-r0/recipe-sysroot-native/usr/bin/i686-poky-linux:/home/akuster/oss/clean/poky/build/tmp/work/core2-32-poky-linux/sssd/2.5.2-r0/recipe-sysroot/usr/bin/crossscripts:/home/akuster/oss/clean/poky/build/tmp/work/core2-32-poky-linux/sssd/2.5.2-r0/recipe-sysroot-native/usr/sbin:/home/akuster/oss/clean/poky/build/tmp/work/core2-32-poky-linux/sssd/2.5.2-r0/recipe-sysroot-native/usr/bin:/home/akuster/oss/clean/poky/build/tmp/work/core2-32-poky-linux/sssd/2.5.2-r0/recipe-sysroot-native/sbin:/home/akuster/oss/clean/poky/build/tmp/work/core2-32-poky-linux/sssd/2.5.2-r0/recipe-sysroot-native/bin:/home/akuster/oss/clean/poky/bitbake/bin:/home/akuster/oss/clean/poky/build/tmp/hosttools"
dpkg-deb -b
/home/akuster/oss/clean/poky/build/tmp/work/core2-32-poky-linux/sssd/2.5.2-r0/packages-split/libsss_sudo
/home/akuster/oss/clean/poky/build/tmp/work/core2-32-poky-linux/sssd/2.5.2-r0/deploy-debs/core2-32'
returned non-zero exit status 2.
Subprocess output:dpkg-deb: error: package name has characters that
aren't lowercase alphanums or '-+.'

ERROR: Logfile of failure stored in:
/home/akuster/oss/clean/poky/build/tmp/work/core2-32-poky-linux/sssd/2.5.2-r0/temp/log.do_package_write_deb.2973553
ERROR: Task
(/home/akuster/oss/maint/meta-security/recipes-security/sssd/sssd_2.5.2.bb:do_package_write_deb)
failed with exit code '1'



So create a new sub-package libsss_sudo to package file libsss_sudo.so
and make sssd rdepends on it.

Signed-off-by: Kai Kang <kai.kang@windriver.com>
---
recipes-security/sssd/sssd_2.5.2.bb | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/recipes-security/sssd/sssd_2.5.2.bb b/recipes-security/sssd/sssd_2.5.2.bb
index 76d6e03..da1a5c3 100644
--- a/recipes-security/sssd/sssd_2.5.2.bb
+++ b/recipes-security/sssd/sssd_2.5.2.bb
@@ -125,10 +125,12 @@ SYSTEMD_SERVICE:${PN} = " \
"
SYSTEMD_AUTO_ENABLE = "disable"
-FILES:${PN} += "${libdir} ${datadir} ${base_libdir}/security/pam_sss*.so"
-FILES:${PN}-dev = " ${includedir}/* ${libdir}/*la ${libdir}/*/*la"
-
-# The package contains symlinks that trip up insane
-INSANE_SKIP:${PN} = "dev-so"
-
-RDEPENDS:${PN} = "bind bind-utils dbus libldb libpam"
+PACKAGES =+ "libsss_sudo"
+FILES:${PN} += "${base_libdir}/security/pam_sss*.so \
+ ${datadir}/dbus-1/system-services/*.service \
+ ${libdir}/krb5/* \
+ ${libdir}/ldb/* \
+ "
+FILES:libsss_sudo = "${libdir}/libsss_sudo.so"
+
+RDEPENDS:${PN} = "bind bind-utils dbus libldb libpam libsss_sudo"


--
Kai Kang
Wind River Linux


Re: #zeus meta-intel #zeus

Anuj Mittal
 

There are no patches needed other than what is already in oe-core/meta-
intel/meta-clang. I tried building zeus on Ubuntu 16.04 and didn't see
any problem.

zeus is no longer maintained or supported so I'd suggest checking a
newer release or experimenting without using buildtools to see if that
is exposing this problem. It does look like things are not being
compiled properly or perhaps opencl-clang-native is linking to
incorrect LLVM ...

Thanks,

Anuj

On Wed, 2021-10-13 at 16:53 +0000, Monsees, Steven C (US) wrote:

Anything ?, I have yet to resolve this.

-----Original Message-----
From: Monsees, Steven C (US)
Sent: Wednesday, October 13, 2021 9:03 AM
To: 'Mittal, Anuj' <anuj.mittal@intel.com>;
'yocto@lists.yoctoproject.org' <yocto@lists.yoctoproject.org>
Subject: RE: [yocto] #zeus meta-intel


Are there any patches required for these components (igc, opencl-
clang, and intel-compute-runtime) ?

-----Original Message-----
From: Monsees, Steven C (US)
Sent: Wednesday, October 13, 2021 7:13 AM
To: 'Mittal, Anuj' <anuj.mittal@intel.com>;
yocto@lists.yoctoproject.org
Subject: RE: [yocto] #zeus meta-intel


Anuj:

I rebuilt the entire image (but did not delete the state_cache)...
I am building meta-clang (zeus based, I believe it is 9.0.1).

Steve

-----Original Message-----
From: Mittal, Anuj <anuj.mittal@intel.com>
Sent: Tuesday, October 12, 2021 10:10 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>;
yocto@lists.yoctoproject.org
Subject: Re: [yocto] #zeus meta-intel

External Email Alert

This email has been sent from an account outside of the BAE Systems
network.

Please treat the email with caution, especially if you are requested
to click on a link, decrypt/open an attachment, or enable macros. 
For further information on how to spot phishing, access
“Cybersecurity OneSpace Page” and report phishing by clicking the
button “Report Phishing” on the Outlook toolbar.


Did you build everything with this compiler from start? Is opencl-
clang building with the right LLVM lib from meta-clang?

Thanks,

Anuj

On Tue, 2021-10-12 at 17:15 +0000, Monsees, Steven C (US) wrote:

Anuj:

I picked up the tarball for for the baseline dunfell tools platform
to
update host tools...

I am seeing it compile cleaner but for one issue causng ld to fail:

/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:1331:
undefined reference to `vtable for
llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>,
std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >'

Isn't LLVM brought in along with clang under meta-clang ?

Is there a missing build dependency ?

Thanks,
Steve

Build excerpt showing multiple " undefined reference to `vtable "
errors...

/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >::~opt()':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:1331:
undefined reference to `vtable for
llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>,
std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::OptionValue<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >::OptionValue()':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:601:
undefined reference to `vtable for
llvm::cl::OptionValue<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >
::opt<llvm::cl::FormattingFlags, llvm::cl::desc,
llvm::cl::desc const&, llvm::cl::initializer<char [2]> const&)':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:1407:
undefined reference to `vtable for
llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>,
std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >
::parser(llvm::cl::Option&)':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:1072:
undefined reference to `vtable for
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >::~opt()':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:1331:
undefined reference to `vtable for
llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>,
std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::OptionValue<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >::OptionValue()':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:601:
undefined reference to `vtable for
llvm::cl::OptionValue<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >::opt<char [9],
llvm::cl::desc>(char const (&) [9], llvm::cl::desc const&)':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:1407:
undefined reference to `vtable for
llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>,
std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >
::parser(llvm::cl::Option&)':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:1072:
undefined reference to `vtable for
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >'
collect2: error: ld returned 1 exit status

-----Original Message-----
From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org>
On
Behalf Of Anuj Mittal
Sent: Tuesday, October 12, 2021 10:43 AM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>;
yocto@lists.yoctoproject.org
Subject: Re: [yocto] #zeus meta-intel

External Email Alert

network.

Please treat the email with caution, especially if you are
requested
to click on a link, decrypt/open an attachment, or enable macros. 
For
further information on how to spot phishing, access “Cybersecurity
OneSpace Page” and report phishing by clicking the button “Report
Phishing” on the Outlook toolbar.


On Tue, 2021-10-12 at 12:43 +0000, Monsees, Steven C (US) wrote:
g++: error: unrecognized command line option ‘-std=c++14’
It looks like the gcc version is too old on your host for this to
work.

Thanks,

Anuj


BB file to build USBIP tools, looking for feedback. Was: building the kernel's usbipd daemon

chuck kamas
 

I have successfully gotten yocto to build the USBIP-tools directory by adding a bb recipe for it, see below. However, I am sure that I have violated ever good and reasonable best practice! Therefore I am looking for feedback on how to improve the recipe before I attempt to submit it for inclusion in the database.


Feedback is welcome and desired! So please comment.


The issues I had to solve to get this recipe to work are:

1) the kernel source is removed from the tmp/work-shared/raspberrypi-cm3/kernel-source when the kernel is done building. I have not figured out how to keep this code populated so that this recipe can access it.  I have tried adding

DEPENDS = "virtual/kernel"

but this did not seem to keep the code around. Is there a best practice for this?


2) the code is in kernel-source/tools/usb/usbip, and is based on autotools. However, those autotools are hidden behind a few scrips:

autogen.sh -> runs "autoreconf -i -f -v"

and

cleanup.sh -> removes all of the autogen code.


The issue I am having is that these shell scripts are currently modifying the work-shared/... copy and not a local copy. Should I be concerned? If so how to copy the code to a more reasonable place and then modify it? I saw something in the comments of the perf.bb code that seams to do this....

3) is there a way to use (or should I) the autotools.bbclass? I have taken some code out of there to properly setup for the configure step. However, I feel that this is a dumb solution and I would rather reuse a class here. But, as far as I can tell the autotools needs to load the code from git and then configure it, but I only need the tools/usb/usbip directory of the kernel.

4) If I were to use the autotools class it is looking for .config files, but these are generated by the autoreconf program. How do I get the class to kick this off? do_configure_prepend ()??


I think that is enough questions for now.

Thank you all for your help!

Chuck


-----------------code start-----------------------

SUMMARY = "USBip part of Linux kernel built in tools"
DESCRIPTION = " USB/IP protocol allows to pass USB device from server to \
client over the network. Server is a machine which provides (shares) a \
USB device. Client is a machine which uses USB device provided by server \
over the network. The USB device may be either physical device connected \
to a server or software entity created on a server using USB gadget subsystem."

LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6"
DEPENDS = "virtual/kernel libtool udev"
PROVIDES = "virtual/usbip-tools"

inherit linux-kernel-base kernel-arch kernelsrc manpages


do_populate_lic[depends] += "virtual/kernel:do_patch"
do_configure[depends] += "virtual/kernel:do_shared_workdir"

EXTRA_OEMAKE = "\
    -C ${S}/tools/usb/usbip \
    O=${B} \
    CROSS_COMPILE=${TARGET_PREFIX} \
    CROSS=${TARGET_PREFIX} \
    CC="${CC}" \
    CCLD="${CC}" \
    LD="${LD}" \
    AR="${AR}" \
    ARCH="${ARCH}" \
    TMPDIR="${B}" \
"

EXTRA_OEMAKE += "\
    'DESTDIR=${D}' \
    KERNEL_SRC=${STAGING_KERNEL_DIR} \
"

do_configure[depends] += "virtual/kernel:do_shared_workdir"

inherit autotools gettext

# stolen from autotools.bbclass

CONFIGUREOPTS = " --build=${BUILD_SYS} \
          --host=${HOST_SYS} \
          --target=${TARGET_SYS} \
          --prefix=${prefix} \
          --exec_prefix=${exec_prefix} \
          --bindir=${bindir} \
          --sbindir=${sbindir} \
          --libexecdir=${libexecdir} \
          --datadir=${datadir} \
          --sysconfdir=${sysconfdir} \
          --sharedstatedir=${sharedstatedir} \
          --localstatedir=${localstatedir} \
          --libdir=${libdir} \
          --includedir=${includedir} \
          --oldincludedir=${oldincludedir} \
          --infodir=${infodir} \
          --mandir=${mandir} \
          --disable-silent-rules \
          ${CONFIGUREOPT_DEPTRACK} \
          ${@append_libtool_sysroot(d)} \
"

do_configure_prepend () {
    cd ${S}/tools/usb/usbip
    ./cleanup.sh
    ./autogen.sh
    ./configure ${CONFIGUREOPTS} ${EXTRA_OECONF}
}

do_compile() {
    oe_runmake
}

do_install() {
    oe_runmake DESTDIR=${D} install
}

PACKAGE_ARCH = "${MACHINE_ARCH}"

python do_package_prepend() {
    d.setVar('PKGV', d.getVar("KERNEL_VERSION", True).split("-")[0])
}

B = "${WORKDIR}/${BPN}-${PV}"


[meta-security][PATCH] python3-fail2ban: fix build failure and cleanup

Armin Kuster
 

Fixes:
error in fail2ban setup command: use_2to3 is invalid.
ERROR: 'python3 setup.py build ' execution failed.

drop custom fail2ban_setup.py
remove pyhton-fail2ban as its a symlink to python3

Update to tip for 11.2 branch

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
.../fail2ban/files/fail2ban_setup.py | 174 ------------------
.../fail2ban/python3-fail2ban_0.11.2.bb | 8 +-
2 files changed, 4 insertions(+), 178 deletions(-)
delete mode 100755 recipes-security/fail2ban/files/fail2ban_setup.py

diff --git a/recipes-security/fail2ban/files/fail2ban_setup.py b/recipes-security/fail2ban/files/fail2ban_setup.py
deleted file mode 100755
index e231949..0000000
--- a/recipes-security/fail2ban/files/fail2ban_setup.py
+++ /dev/null
@@ -1,174 +0,0 @@
-# emacs: -*- mode: python; py-indent-offset: 4; indent-tabs-mode: t -*-
-# vi: set ft=python sts=4 ts=4 sw=4 noet :
-
-# This file is part of Fail2Ban.
-#
-# Fail2Ban is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 2 of the License, or
-# (at your option) any later version.
-#
-# Fail2Ban is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with Fail2Ban; if not, write to the Free Software
-# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-
-__author__ = "Cyril Jaquier, Steven Hiscocks, Yaroslav Halchenko"
-__copyright__ = "Copyright (c) 2004 Cyril Jaquier, 2008-2016 Fail2Ban Contributors"
-__license__ = "GPL"
-
-import platform
-
-try:
- import setuptools
- from setuptools import setup
- from setuptools.command.install import install
- from setuptools.command.install_scripts import install_scripts
-except ImportError:
- setuptools = None
- from distutils.core import setup
-
-# all versions
-from distutils.command.build_py import build_py
-from distutils.command.build_scripts import build_scripts
-if setuptools is None:
- from distutils.command.install import install
- from distutils.command.install_scripts import install_scripts
-try:
- # python 3.x
- from distutils.command.build_py import build_py_2to3
- from distutils.command.build_scripts import build_scripts_2to3
- _2to3 = True
-except ImportError:
- # python 2.x
- _2to3 = False
-
-import os
-from os.path import isfile, join, isdir, realpath
-import sys
-import warnings
-from glob import glob
-
-from fail2ban.setup import updatePyExec
-
-if setuptools and "test" in sys.argv:
- import logging
- logSys = logging.getLogger("fail2ban")
- hdlr = logging.StreamHandler(sys.stdout)
- fmt = logging.Formatter("%(asctime)-15s %(message)s")
- hdlr.setFormatter(fmt)
- logSys.addHandler(hdlr)
- if set(["-q", "--quiet"]) & set(sys.argv):
- logSys.setLevel(logging.CRITICAL)
- warnings.simplefilter("ignore")
- sys.warnoptions.append("ignore")
- elif set(["-v", "--verbose"]) & set(sys.argv):
- logSys.setLevel(logging.DEBUG)
- else:
- logSys.setLevel(logging.INFO)
-elif "test" in sys.argv:
- print("python distribute required to execute fail2ban tests")
- print("")
-
-longdesc = '''
-Fail2Ban scans log files like /var/log/pwdfail or
-/var/log/apache/error_log and bans IP that makes
-too many password failures. It updates firewall rules
-to reject the IP address or executes user defined
-commands.'''
-
-if setuptools:
- setup_extra = {
- 'test_suite': "fail2ban.tests.utils.gatherTests",
- 'use_2to3': True,
- }
-else:
- setup_extra = {}
-
-data_files_extra = []
-
-# Installing documentation files only under Linux or other GNU/ systems
-# (e.g. GNU/kFreeBSD), since others might have protective mechanisms forbidding
-# installation there (see e.g. #1233)
-platform_system = platform.system().lower()
-doc_files = ['README.md', 'DEVELOP', 'FILTERS', 'doc/run-rootless.txt']
-if platform_system in ('solaris', 'sunos'):
- doc_files.append('README.Solaris')
-if platform_system in ('linux', 'solaris', 'sunos') or platform_system.startswith('gnu'):
- data_files_extra.append(
- ('/usr/share/doc/fail2ban', doc_files)
- )
-
-# Get version number, avoiding importing fail2ban.
-# This is due to tests not functioning for python3 as 2to3 takes place later
-exec(open(join("fail2ban", "version.py")).read())
-
-setup(
- name = "fail2ban",
- version = version,
- description = "Ban IPs that make too many password failures",
- long_description = longdesc,
- author = "Cyril Jaquier & Fail2Ban Contributors",
- author_email = "cyril.jaquier@fail2ban.org",
- url = "http://www.fail2ban.org",
- license = "GPL",
- platforms = "Posix",
- cmdclass = {
- 'build_py': build_py, 'build_scripts': build_scripts,
- },
- scripts = [
- 'bin/fail2ban-client',
- 'bin/fail2ban-server',
- 'bin/fail2ban-regex',
- 'bin/fail2ban-testcases',
- # 'bin/fail2ban-python', -- link (binary), will be installed via install_scripts_f2b wrapper
- ],
- packages = [
- 'fail2ban',
- 'fail2ban.client',
- 'fail2ban.server',
- 'fail2ban.tests',
- 'fail2ban.tests.action_d',
- ],
- package_data = {
- 'fail2ban.tests':
- [ join(w[0], f).replace("fail2ban/tests/", "", 1)
- for w in os.walk('fail2ban/tests/files')
- for f in w[2]] +
- [ join(w[0], f).replace("fail2ban/tests/", "", 1)
- for w in os.walk('fail2ban/tests/config')
- for f in w[2]] +
- [ join(w[0], f).replace("fail2ban/tests/", "", 1)
- for w in os.walk('fail2ban/tests/action_d')
- for f in w[2]]
- },
- data_files = [
- ('/etc/fail2ban',
- glob("config/*.conf")
- ),
- ('/etc/fail2ban/filter.d',
- glob("config/filter.d/*.conf")
- ),
- ('/etc/fail2ban/filter.d/ignorecommands',
- [p for p in glob("config/filter.d/ignorecommands/*") if isfile(p)]
- ),
- ('/etc/fail2ban/action.d',
- glob("config/action.d/*.conf") +
- glob("config/action.d/*.py")
- ),
- ('/etc/fail2ban/fail2ban.d',
- ''
- ),
- ('/etc/fail2ban/jail.d',
- ''
- ),
- ('/var/lib/fail2ban',
- ''
- ),
- ] + data_files_extra,
- **setup_extra
-)
diff --git a/recipes-security/fail2ban/python3-fail2ban_0.11.2.bb b/recipes-security/fail2ban/python3-fail2ban_0.11.2.bb
index ed75a0e..627496f 100644
--- a/recipes-security/fail2ban/python3-fail2ban_0.11.2.bb
+++ b/recipes-security/fail2ban/python3-fail2ban_0.11.2.bb
@@ -9,10 +9,9 @@ HOMEPAGE = "http://www.fail2ban.org"
LICENSE = "GPL-2.0"
LIC_FILES_CHKSUM = "file://COPYING;md5=ecabc31e90311da843753ba772885d9f"

-SRCREV ="eea1881b734b73599a21df2bfbe58b11f78d0a46"
+SRCREV ="d6b884f3b72b8a42b21da863836569ef6836c2ea"
SRC_URI = " git://github.com/fail2ban/fail2ban.git;branch=0.11 \
file://initd \
- file://fail2ban_setup.py \
file://run-ptest \
"

@@ -20,13 +19,13 @@ inherit update-rc.d ptest setuptools3

S = "${WORKDIR}/git"

-do_compile:prepend () {
- cp ${WORKDIR}/fail2ban_setup.py ${S}/setup.py
+do_compile () {
cd ${S}
./fail2ban-2to3
}

do_install:append () {
+ rm -f ${D}/${bindir}/fail2ban-python
install -d ${D}/${sysconfdir}/fail2ban
install -d ${D}/${sysconfdir}/init.d
install -m 0755 ${WORKDIR}/initd ${D}${sysconfdir}/init.d/fail2ban-server
@@ -38,6 +37,7 @@ do_install_ptest:append () {
install -d ${D}${PTEST_PATH}/bin
sed -i -e 's/##PYTHON##/${PYTHON_PN}/g' ${D}${PTEST_PATH}/run-ptest
install -D ${S}/bin/* ${D}${PTEST_PATH}/bin
+ rm -f ${D}${PTEST_PATH}/bin/fail2ban-python
}

FILES:${PN} += "/run"
--
2.25.1


Re: How to enable graphics acceleration on qemux86-64?

Alexander Kanavin
 

If you switch to master, it's best if you make a new build directory and dont reuse the one you have.

Alex


On Wed, 13 Oct 2021 at 22:09, Manuel Wagesreither <ManWag@...> wrote:
`export DISPLAY=:0` did the trick.

The following shows when still on poky dunfell:

* I can now boot `runqmu kvm slirp sdl core-image-weston`. But gui is still slow. I cannot even type `systemctl poweroff` in weston-terminal, it inevitably becomes `wweesssttooo[...]`.
* `runqemu kvm slirp sdl gl core-image-weston` still fails with `Failed to run qemu: qemu-system-x86_64: OpenGL support is disabled`.

Updated to current poky master, but got this: `ERROR: ParseError in configuration INHERITs: Could not inherit file classes/image-mklibs.bbclass`.

Switched to hardknott-3.3.3 which is four weeks old and perhaps a little riper. It's currently building.

Regards,
Manuel

2061 - 2080 of 57104