blacklist for now. Remove from pkg grp

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-core/packagegroup/packagegroup-core-security.bb | 1 -
recipes-security/libest/libest_3.2.0.bb | 3 +++
2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/recipes-core/packagegroup/packagegroup-core-security.bb b/recipes-core/packagegroup/packagegroup-core-security.bb
index e9dad5b..fefc66d 100644
--- a/recipes-core/packagegroup/packagegroup-core-security.bb
+++ b/recipes-core/packagegroup/packagegroup-core-security.bb
@@ -38,7 +38,6 @@ RDEPENDS:packagegroup-security-utils = "\
python3-privacyidea \
python3-fail2ban \
softhsm \
- libest \
sshguard \
${@bb.utils.contains_any("TUNE_FEATURES", "riscv32 ", "", " libseccomp",d)} \
${@bb.utils.contains("DISTRO_FEATURES", "pam", "sssd google-authenticator-libpam", "",d)} \
diff --git a/recipes-security/libest/libest_3.2.0.bb b/recipes-security/libest/libest_3.2.0.bb
index 31fbe3c..41a4025 100644
--- a/recipes-security/libest/libest_3.2.0.bb
+++ b/recipes-security/libest/libest_3.2.0.bb
@@ -25,3 +25,6 @@ S = "${WORKDIR}/git"
PACKAGES = "${PN} ${PN}-dbg ${PN}-dev"

FILES:${PN} = "${bindir}/* ${libdir}/libest-3.2.0p.so"
+
+# https://github.com/cisco/libest/issues/104
+PNBLACKLIST[libest] ?= "Needs porting to openssl 3.x"
--
2.25.1

All,

As previously announced, OpenEmbedded Developer Virtual Meeting will take
place on December 3 from 12:00 UTC until 20:00 UTC:

https://www.openembedded.org/wiki/OEDVM_Nov_2021

Once the meeting is over, everybody is invited to hang out and relax at
the OpenEmbedded Happy Hour, which tentatively will start at 20:00 UTC
(3pm ET / 12pm PT):

https://www.openembedded.org/wiki/Happy_Hours
https://www.openembedded.org/wiki/Calendar
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenEmbedded+Happy+Hour+December+3&iso=20211203T20

--
Regards,
Denys Dmytriyenko <denis@...>
PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964
Fingerprint: 25FC E4A5 8A72 2F69 1186 6D76 4209 0272 9A92 C964

Hi,

On Fri, Nov 26, 2021 at 11:55 PM Trevor Woerner <twoerner@...> wrote:

On Thu 2021-11-11 @ 08:44:48 AM, Marek Belisko wrote:

Hello,

I'm trying to integrate mender for tinker-board-s using meta-rockchip
dunfell branch. When added meta-mender which add few patches to
u-boot I'm seeing u-boot compilation issues like:

Error: SPL image is too large (size 0x11000 than 0x8000)
| Error: Bad parameters for image type

Error is clear to me but patches which mender adds are related mostly
to the environment so I'm not sure how SPL can increase size. Any
ideas on how to resolve this issue?

Does the following help?

I'm adding dunfell support for mender :). In this link mender rockchip
integration is for older u-boot not 2020.01

https://github.com/mendersoftware/meta-mender-community/tree/dunfell/meta-mender-rockchip

BR,

marek

--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

Thanks Tim for the link, I have built the iwd.

According to Daniel's advice to configure with "--disable-wifi,
--enable-iwd", I added PACKAGECONFIG[wifi] = "--disable-wifi,
--enable-iwd", to override PACKAGECONFIG[wifi] in oe-core
connman_1.40.bb. The intention is to remove wpa-supplicant and to add
iwd to connman_1.40.bbappend, it built the image without error, I
believe that the syntax is OK, but the wpa-supplicant was still built
and packaged. Any idea from OE/Yocto insiders why PACKAGECONFIG[wifi]
in bbappend is not effective?

Daniel, how can I verify in the Linux console if the connmand is
running with iwd or with wpa_supplicant? I have disabled
wpa_supplicant.service, and I'll remove wpa_supplicant completely when
I find a way to do it.

Thank you.

Kind regards,

- jh
On 11/27/21, Tim Orling <ticotimo@...> wrote:

On Fri, Nov 26, 2021 at 5:48 PM Tim Orling via lists.yoctoproject.org
<ticotimo=gmail.com@...> wrote:

On Thu, Nov 25, 2021 at 10:26 PM JH <jupiter.hce@...> wrote:

Hi,

Given the high profile of iwd and advocating connman with iwd, I
believe someone have already built Yocto connman and iwd,
surprisingly, I could not even find an iwd recipe in
https://github.com/openembedded/openembedded/tree/master/recipes, nor
can I find connman document and instructions to replace wpa_supplicant
by iwd, what could I be missing here?

Please look at the layer index for recipes:
https://layers.openembedded.org/layerindex/branch/master/layers/

I don’t have any advice for building it however.

I forgot to include the recipe link:
https://layers.openembedded.org/layerindex/recipe/89268/

Appreciate your kind advice.

Thank you.

Kind regards,

- jh


On 11/26/21, JH via lists.yoctoproject.org
<jupiter.hce=gmail.com@...> wrote:

Hi,

Please correct me, but it seems to me the connman is moving to a
direction to ditch out wpa_supplicant and to use iwd, but the Honister
still configure connman with wpa_supplicant by default, appreciate
your advice:

- Is connman with iwd stable enough?

- How can I create a connman_1.40.bbappend to replace wpa_supplicant
by iwd configure?

- Where are the documents for configuring and building connman with
iwd? Where is the operational guidance to run connman with iwd? Can I
use the same connman dbus APIs or are there any dbus API changes to
run connman with iwd?

My apology for FAQs.

Thank you very much.

Kind regards,

- JH

--
"A man can fail many times, but he isn't a failure until he begins to
blame somebody else."
-- John Burroughs

--
"A man can fail many times, but he isn't a failure until he begins to
blame somebody else."
-- John Burroughs

On Thu 2021-11-11 @ 08:44:48 AM, Marek Belisko wrote:

Hello,

I'm trying to integrate mender for tinker-board-s using meta-rockchip
dunfell branch. When added meta-mender which add few patches to
u-boot I'm seeing u-boot compilation issues like:

Error: SPL image is too large (size 0x11000 than 0x8000)
| Error: Bad parameters for image type

Error is clear to me but patches which mender adds are related mostly
to the environment so I'm not sure how SPL can increase size. Any
ideas on how to resolve this issue?

Does the following help?
https://github.com/mendersoftware/meta-mender-community/tree/dunfell/meta-mender-rockchip

merged.

Hi,

Given the high profile of iwd and advocating connman with iwd, I
believe someone have already built Yocto connman and iwd,
surprisingly, I could not even find an iwd recipe in
https://github.com/openembedded/openembedded/tree/master/recipes, nor
can I find connman document and instructions to replace wpa_supplicant
by iwd, what could I be missing here?

Appreciate your kind advice.

Thank you.

Kind regards,

- jh


On 11/26/21, JH via lists.yoctoproject.org
<jupiter.hce=gmail.com@...> wrote:

Hi,

Please correct me, but it seems to me the connman is moving to a
direction to ditch out wpa_supplicant and to use iwd, but the Honister
still configure connman with wpa_supplicant by default, appreciate
your advice:

- Is connman with iwd stable enough?

- How can I create a connman_1.40.bbappend to replace wpa_supplicant
by iwd configure?

- Where are the documents for configuring and building connman with
iwd? Where is the operational guidance to run connman with iwd? Can I
use the same connman dbus APIs or are there any dbus API changes to
run connman with iwd?

My apology for FAQs.

Thank you very much.

Kind regards,

- JH

--
"A man can fail many times, but he isn't a failure until he begins to
blame somebody else."
-- John Burroughs

Hi,

Please correct me, but it seems to me the connman is moving to a
direction to ditch out wpa_supplicant and to use iwd, but the Honister
still configure connman with wpa_supplicant by default, appreciate
your advice:

- Is connman with iwd stable enough?

- How can I create a connman_1.40.bbappend to replace wpa_supplicant
by iwd configure?

- Where are the documents for configuring and building connman with
iwd? Where is the operational guidance to run connman with iwd? Can I
use the same connman dbus APIs or are there any dbus API changes to
run connman with iwd?

My apology for FAQs.

Thank you very much.

Kind regards,

- JH

Hi guys, 

I have an issue related to vardeps where I am making a task dependent on some variables. 

I have created some new variables e.g., NEW_VARIABLE, added them to BB_ENV_EXTRAWHITE. In some recipes, I wrote my own implementation of some tasks that are dependent on these new variables, and for this dependency to work I added  e.g., do_install[vardeps] = "NEW_VARIABLE", so I am now expecting that every time I change this NEW_VARIABLE and perform e.g., "bitbake recipename", the do_install task should run. I checked the task signature and I see the NEW_VARIABLE there.

Let's assum I have two possible values for this variable. When I set the variable for the first time "value1", i.e., the first build, everything works and there is no problem. When I change its value to the other value "value2" not used before and build the recipe again, the do_install will also run and no problem occurs. The problem is however, if I set the variable again to the old value "value1", and I execite "bitbake recipename" again. The do_install will not be re-triggered, and this leads to some wrong/old data located in work directory, and also produced in the image. 

I tried setting BB_DONT_CACHE, as I understood in an old topic that the problem might be that the recipe needs to be parsed again, however this did not work at all.

I do not want to always run the tasks when I perform a new build, i.e., do_install[[nostamp] = "1", I just want it to run again every time I change this NEW_VARIABLE.

Is what I am expecting a normal behavior? Or Yocto does not work this way?

Regards
Mohannad

No meeting next week - YP Summit

Publish the generic-arm64 binaries in a dedicated meta-arm/ directory so
it is clear this isn't from the core layers.

Signed-off-by: Ross Burton <ross.burton@...>
---
scripts/publish-artefacts | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/scripts/publish-artefacts b/scripts/publish-artefacts
index 6ed922a..9795381 100755
--- a/scripts/publish-artefacts
+++ b/scripts/publish-artefacts
@@ -187,6 +187,11 @@ case "$target" in
sha256sums $TMPDIR/deploy/images/genericx86
cp -R --no-dereference --preserve=3Dlinks $TMPDIR/deploy/images/=
genericx86/*genericx86* $DEST/machines/genericx86-alt
;;
+ "meta-arm")
+ mkdir -p $DEST/machines/meta-arm/generic-arm64
+ sha256sums $TMPDIR/deploy/images/generic-arm64
+ cp -R --no-dereference --preserve=3Dlinks $TMPDIR/deploy/images/=
generic-arm64/*generic-arm64* $DEST/machines/meta-arm/generic-arm64
+ ;;
"poky-tiny")
mkdir -p $DEST/machines/qemu/qemu-tiny
sha256sums $TMPDIR/deploy/images/qemux86
--=20
2.25.1

On Wed, 2021-11-24 at 09:55 -0800, Tim Orling wrote:

On Mon, Nov 22, 2021 at 2:54 PM David Babich <ddbabich@...>
wrote:

I made it a little further by adding --no-cache-dir to the pip3
install command.  That got rid fo the warning about not being able
to access the .cache/pip.  However I still have the error:
| ERROR: torch-1.10.0-cp36-cp36m-linux_aarch64.whl is not a
supported wheel on this platform.

Installing third-party wheels is not something we are likely to ever
support in Yocto Project/OpenEmbedded recipes.

Are you trying to install using pip3 on target?
Note that many factors will make it tricky for python wheels with
binary content (C or Rust extensions). The python3 version must
match, as will the libraries it requires. 

The wheel you listed was built for Python 3.6 (cp36) and ARM v8
(aarch64).  The error is what you would see if you were trying to
install an aarch64 wheel on an x86-64 target, but other reasons could
lead to that error. We don't know what version of glibc, gcc, etc.
was used and whether those are going to be compatible.

There's a section about building from source with a patch in the
article he linked with his first message. I don't know much about
python in yocto, but maybe doing that in a recipe could work?

Also, when asking questions, please tell us which release of Yocto
Project you are using, what the MACHINE you are building for is,
which layers you are using (and at what release) and other
information to help us help you.

Cheers,
--Tim

Thanks for the reply,

I tried adding IMAGE_LINGUAS = " ", it passes but do_image_cpio gives nothing (means no image.gpio.gz) is generated.
I don't know why.

On Wed, 2021-11-24 at 19:21 -0500, Mohammed Billoo wrote:

Hi,

I need to add TI MCU firmware as part of an OE/Yocto build for a
project that I am working on. Basically, the firmware needs to be
built during the overall image build and be stored in the RFS. My
strategy to build the firmware was to set up the TI toolchain as part
of the image build. Since I have the toolchain components and believe
it to be unnecessary (if not impossible) to build them from source, I
have the necessary pre-built components (provided by TI) as tarballs
uploaded somewhere.

In determining the best way to use a pre-built toolchain, I just
copied the gcc-linaro-baremetal-arm-native recipe. But, when I go to
bake my recipe for the toolchain, I get the following error:

ERROR: ti-bios-1.0-r0 do_populate_sysroot: Error executing a python
function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: <module>
0001:
*** 0002:uninative_changeinterp(d)
0003:
File: '/home/mbilloo/yocto-builds/norbert/yocto/build-doris/../layers/poky/meta/classes/uninative.bbclass',
lineno: 170, function: uninative_changeinterp
0166: continue
0167: if not elf.isDynamic():
0168: continue
0169:
*** 0170: subprocess.check_output(("patchelf-uninative",
"--set-interpreter", d.getVar("UNINATIVE_LOADER"), f),
stderr=subprocess.STDOUT)
0171:}
File: '/usr/lib64/python3.8/subprocess.py', lineno: 411, function: check_output
0407: # Explicitly passing input=None was previously
equivalent to passing an
0408: # empty string. That is maintained here for
backwards compatibility.
0409: kwargs['input'] = '' if
kwargs.get('universal_newlines', False) else b''
0410:
*** 0411: return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
0412: **kwargs).stdout
0413:
0414:
0415:class CompletedProcess(object):
File: '/usr/lib64/python3.8/subprocess.py', lineno: 512, function: run
0508: # We don't call process.wait() as .__exit__ does
that for us.
0509: raise
0510: retcode = process.poll()
0511: if check and retcode:
*** 0512: raise CalledProcessError(retcode, process.args,
0513: output=stdout, stderr=stderr)
0514: return CompletedProcess(process.args, retcode, stdout, stderr)
0515:
0516:
Exception: subprocess.CalledProcessError: Command
'('patchelf-uninative', '--set-interpreter',
'/home/mbilloo/yocto-builds/norbert/yocto/build-doris/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2',
'/home/mbilloo/yocto-builds/norbert/yocto/build-doris/tmp/work/x86_64-linux/ti-bios/1.0-r0/sstate-build-populate_sysroot/recipe-sysroot-native/usr/share/bios_6_73_01_01/packages/ti/platforms/sim6xxx/Solaris/kelvin')'
returned non-zero exit status 1.

Subprocess output:
patchelf: cannot find section '.gnu.version_r'

It looks like uninative is ultimately being inherited and there are
some steps taken to eliminate any host-dependencies for the toolchain
binaries. Is there a way to disable this inheritance only for this
recipe (if I globally disable uninative in my conf file, the recipe
bakes just fine, but obviously can't do that)? Or, is there a better
way of accomplishing my goal?

You could define a new uninative_changeinterp() function in your recipe to
override the core one and make it do nothing. Not a particularly elegant
solution but should work...

Cheers,

Richard

Hi,

I need to add TI MCU firmware as part of an OE/Yocto build for a
project that I am working on. Basically, the firmware needs to be
built during the overall image build and be stored in the RFS. My
strategy to build the firmware was to set up the TI toolchain as part
of the image build. Since I have the toolchain components and believe
it to be unnecessary (if not impossible) to build them from source, I
have the necessary pre-built components (provided by TI) as tarballs
uploaded somewhere.

In determining the best way to use a pre-built toolchain, I just
copied the gcc-linaro-baremetal-arm-native recipe. But, when I go to
bake my recipe for the toolchain, I get the following error:

ERROR: ti-bios-1.0-r0 do_populate_sysroot: Error executing a python
function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: <module>
0001:
*** 0002:uninative_changeinterp(d)
0003:
File: '/home/mbilloo/yocto-builds/norbert/yocto/build-doris/../layers/poky/meta/classes/uninative.bbclass',
lineno: 170, function: uninative_changeinterp
0166: continue
0167: if not elf.isDynamic():
0168: continue
0169:
*** 0170: subprocess.check_output(("patchelf-uninative",
"--set-interpreter", d.getVar("UNINATIVE_LOADER"), f),
stderr=subprocess.STDOUT)
0171:}
File: '/usr/lib64/python3.8/subprocess.py', lineno: 411, function: check_output
0407: # Explicitly passing input=None was previously
equivalent to passing an
0408: # empty string. That is maintained here for
backwards compatibility.
0409: kwargs['input'] = '' if
kwargs.get('universal_newlines', False) else b''
0410:
*** 0411: return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
0412: **kwargs).stdout
0413:
0414:
0415:class CompletedProcess(object):
File: '/usr/lib64/python3.8/subprocess.py', lineno: 512, function: run
0508: # We don't call process.wait() as .__exit__ does
that for us.
0509: raise
0510: retcode = process.poll()
0511: if check and retcode:
*** 0512: raise CalledProcessError(retcode, process.args,
0513: output=stdout, stderr=stderr)
0514: return CompletedProcess(process.args, retcode, stdout, stderr)
0515:
0516:
Exception: subprocess.CalledProcessError: Command
'('patchelf-uninative', '--set-interpreter',
'/home/mbilloo/yocto-builds/norbert/yocto/build-doris/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2',
'/home/mbilloo/yocto-builds/norbert/yocto/build-doris/tmp/work/x86_64-linux/ti-bios/1.0-r0/sstate-build-populate_sysroot/recipe-sysroot-native/usr/share/bios_6_73_01_01/packages/ti/platforms/sim6xxx/Solaris/kelvin')'
returned non-zero exit status 1.

Subprocess output:
patchelf: cannot find section '.gnu.version_r'

It looks like uninative is ultimately being inherited and there are
some steps taken to eliminate any host-dependencies for the toolchain
binaries. Is there a way to disable this inheritance only for this
recipe (if I globally disable uninative in my conf file, the recipe
bakes just fine, but obviously can't do that)? Or, is there a better
way of accomplishing my goal?

Thanks
--
Mohammed A Billoo
Founder
MAB Labs, LLC
www.mab-labs.com
www.linkedin.com/company/mab-labs
201-338-2022
22 East Quackenbush Ave Suite LL5
Dumont, NJ 07628

--