Date   

Enhancements/Bugs closed WW48!

Stephen Jolley
 

All,

The below were the owners of enhancements or bugs closed during the last week!

Who

Count

richard.purdie@...

2

trevor.gamblin@...

1

anuj.mittal@...

1

randy.macleod@...

1

ernstp@...

1

Grand Total

6

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Current high bug count owners for Yocto Project 3.5

Stephen Jolley
 

All,

Below is the list as of top 46 bug owners as of the end of WW48 of who have open medium or higher bugs and enhancements against YP 3.5.   There are 104 possible work days left until the final release candidates for YP 3.5 needs to be released.

Who

Count

ross@...

36

michael.opdenacker@...

34

david.reyna@...

22

randy.macleod@...

20

bruce.ashfield@...

16

trevor.gamblin@...

15

timothy.t.orling@...

15

sakib.sajal@...

11

JPEWhacker@...

11

richard.purdie@...

8

mhalstead@...

7

kai.kang@...

7

saul.wold@...

6

bluelightning@...

6

kiran.surendran@...

5

hongxu.jia@...

4

chee.yang.lee@...

4

jon.mason@...

3

Qi.Chen@...

3

mshah@...

2

pgowda.cve@...

2

pokylinux@...

2

alejandro@...

2

thomas.perrot@...

1

john.kaldas.enpj@...

1

angolini@...

1

open.source@...

1

nicolas.dechesne@...

1

Martin.Jansa@...

1

vinay.m.engg@...

1

limon.anibal@...

1

elberger@...

1

raj.khem@...

1

alexandre.belloni@...

1

steve@...

1

yf3yu@...

1

aehs29@...

1

jay.shen.teoh@...

1

matthewzmd@...

1

mark.hatle@...

1

yi.zhao@...

1

TicoTimo@...

1

mingli.yu@...

1

kexin.hao@...

1

shachar@...

1

mostthingsweb@...

1

Grand Total

264

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project.  If anyone can help, please take ownership of the bug and send patches!  If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 391 unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now, “3.4”, “3.5, "3.99" and "Future", the more pressing/urgent issues being in "3.4" and then “3.5”.

 

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account).  The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: Problem installing python package from a wheel #bitbake #python

David Babich
 

On Thu, Nov 25, 2021 at 02:45 AM, Nicolas Jeker wrote:
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.
Ah OK, I wasn't aware of the the python naming convention.  That is likely my problem since I'm using Honister which uses Python 3.9.  I pulled the wheel from NVIDIA's forums for pytorch, unfortunately they've not released one for Python 3.9 so I will likely have to create it myself using the build from scratch method described in the article I linked.  Unfortunately this will likely open a new can of worms...
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.

I'm using Honister and the machine is 'jetson-tx2-dev-kit-tx2i', I'm making a custom distro based on the meta-tegra-demo from this:

https://github.com/OE4T

A large part of the problem that I have is that many of these custom packages don't provide a nice .tar.gz pypi source distribution that I could use with the pypi class.  My target install ends up on a spacecraft, so there is a strong desire to have a fully managed build that can just be flashed onto the target tx2i without the need to do any post installation or configuration.  Sadly I'm finding that a lot of these third party dependencies do not lend themselves well to the yocto paradigm.  I'm thinking that I may have to setup the target board, install the third party packages on the target using whatever is required to do that, then copy the build products back to the host and use a bitbake recipe to just do_install:append the built products into the rootfs during the yocto build.  Does that sound feasible?  I've not had to do this before, but it seems like it might be a reasonable approach given the complexity of the situation.


Cheers,
--Tim
Thanks
-David
 

 


Re: [meta-security][PATCH] python3-fail2ban: update to tip

Konrad Weihmann <kweihmann@...>
 

On 29.11.21 16:14, Armin Kuster wrote:
Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
recipes-security/fail2ban/python3-fail2ban_0.11.2.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/recipes-security/fail2ban/python3-fail2ban_0.11.2.bb b/recipes-security/fail2ban/python3-fail2ban_0.11.2.bb
index 4e344c8..f6394cc 100644
--- a/recipes-security/fail2ban/python3-fail2ban_0.11.2.bb
+++ b/recipes-security/fail2ban/python3-fail2ban_0.11.2.bb
@@ -9,7 +9,7 @@ HOMEPAGE = "http://www.fail2ban.org"
LICENSE = "GPL-2.0"
LIC_FILES_CHKSUM = "file://COPYING;md5=ecabc31e90311da843753ba772885d9f"
-SRCREV ="d6b884f3b72b8a42b21da863836569ef6836c2ea"
+SRCREV ="4fe4ac8dde6ba14841da598ec37f8c6911fe0f64"
according to github 80805cabfcf57dd0454d47d7f86d43c6738ce629 is the tip.
any specific reason to pick the commit before that?

SRC_URI = " git://github.com/fail2ban/fail2ban.git;branch=0.11;protocol=https \
file://initd \
file://run-ptest \


Re: [meta-rockchip] dunfell: u-boot build issue when added patch to u-boot

Tom Rini
 

On Sat, Nov 27, 2021 at 09:24:56PM +0100, Marek Belisko wrote:
Hi,

On Fri, Nov 26, 2021 at 11:55 PM Trevor Woerner <twoerner@gmail.com> 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
Did some sort of "enable environment support in SPL" option get enabled
in your patches perhaps?

--
Tom


[meta-security][PATCH] python3-fail2ban: update to tip

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
recipes-security/fail2ban/python3-fail2ban_0.11.2.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-security/fail2ban/python3-fail2ban_0.11.2.bb b/recipes-security/fail2ban/python3-fail2ban_0.11.2.bb
index 4e344c8..f6394cc 100644
--- a/recipes-security/fail2ban/python3-fail2ban_0.11.2.bb
+++ b/recipes-security/fail2ban/python3-fail2ban_0.11.2.bb
@@ -9,7 +9,7 @@ HOMEPAGE = "http://www.fail2ban.org"
LICENSE = "GPL-2.0"
LIC_FILES_CHKSUM = "file://COPYING;md5=ecabc31e90311da843753ba772885d9f"

-SRCREV ="d6b884f3b72b8a42b21da863836569ef6836c2ea"
+SRCREV ="4fe4ac8dde6ba14841da598ec37f8c6911fe0f64"
SRC_URI = " git://github.com/fail2ban/fail2ban.git;branch=0.11;protocol=https \
file://initd \
file://run-ptest \
--
2.25.1


define extended partition in wks file

Silvan Murer
 

Hi,
I'm using wic for creating a boot image in my yocto layer. An extended
partition is automatically created, when build an image with more than
four partitions.
The extended partition is added at the end and in my case, the last
two logic partitions are included there.

Does an option exist which allows the definition of the partitions
which are included in the extended partition? In may case, I'm looking
for an option to put the two rootfs partitions (rootfs1 and rootfs2)
into a common extended partition. And the data partition at the end
should be in its own logic partition. Does some option exist or is it
possible to handle them in another way? probably by creating an own
wic plugin?

The *.wks file contains the following entries:

part --source rawcopy --sourceparams="file=u-boot-splx4.sfp" --ondisk
mmcblk0 --system-id=a2 --align 1024 --fixed-size 10M
part /run/mount/bootloader --source bootimg-partition --ondisk mmcblk0
--fstype=vfat --label boot --active --align 1024 --size 500M
part / --source rootfs --ondisk mmcblk0 --fstype=ext4 --label rootfs1
--align 1024 --fixed-size 2G
part --source rootfs --ondisk mmcblk0 --fstype=ext4 --label rootfs2
--align 1024 --fixed-size 2G
part /run/mount/data --ondisk mmcblk0 --fstype=ext4 --label data
--align 1024 --fixed-size 3G

Thanks,
Silvan


Re: [meta-security][PATCH 2/2] meta-parsec/README.md: fix for append operator combined with +=

Armin Kuster
 

thanks.

merged.

On 11/19/21 7:18 AM, Yi Zhao wrote:
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
---
meta-parsec/README.md | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta-parsec/README.md b/meta-parsec/README.md
index c5635d3..bb4c2b9 100644
--- a/meta-parsec/README.md
+++ b/meta-parsec/README.md
@@ -80,7 +80,7 @@ Manual testing with runqemu
This layer also contains a recipe for pasec-tool which can be used for
manual testing of the Parsec service:

- IMAGE_INSTALL:append += " parsec-tools"
+ IMAGE_INSTALL:append = " parsec-tools"

There are a series of Parsec Demo videos showing how to use parsec-tool
to test the Parsec service base functionality:
@@ -104,7 +104,7 @@ enabled. No changes required.
The Software HSM can be used for manual testing of the provider by
including it into your test image:

- IMAGE_INSTALL:append += " softhsm"
+ IMAGE_INSTALL:append = " softhsm"

Inside the running VM:
- Stop Parsec
@@ -135,7 +135,7 @@ systemctl start parsec
The IBM Software TPM service can be used for manual testing of the provider by
including it into your test image:

- IMAGE_INSTALL:append += " ibmswtpm2 tpm2-tools libtss2 libtss2-tcti-mssim"
+ IMAGE_INSTALL:append = " ibmswtpm2 tpm2-tools libtss2 libtss2-tcti-mssim"

Inside the running VM:
- Stop Parsec



Re: [meta-security][PATCH 1/2] openssl-tpm-engine: fix warning for append operator combined with +=

Armin Kuster
 

merged.

thanks

On 11/19/21 7:18 AM, Yi Zhao wrote:
Fixes:
WARNING: openssl-tpm-engine_0.5.0.bb: CFLAGS:append += is not a
recommended operator combination, please replace it.

Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
---
.../openssl-tpm-engine/openssl-tpm-engine_0.5.0.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-tpm/recipes-tpm/openssl-tpm-engine/openssl-tpm-engine_0.5.0.bb b/meta-tpm/recipes-tpm/openssl-tpm-engine/openssl-tpm-engine_0.5.0.bb
index ef663eb..2b969ed 100644
--- a/meta-tpm/recipes-tpm/openssl-tpm-engine/openssl-tpm-engine_0.5.0.bb
+++ b/meta-tpm/recipes-tpm/openssl-tpm-engine/openssl-tpm-engine_0.5.0.bb
@@ -35,10 +35,10 @@ inherit autotools-brokensep pkgconfig
srk_dec_pw ?= "\\"\\\x1\\"\\"nc\\"\\"\\\x3\\"\\"nd\\"\\"\\\x1\\"\\"a\\""
srk_dec_salt ?= "\\"r\\"\\"\\\x00\\\x00\\"\\"t\\""

-CFLAGS:append += "-DSRK_DEC_PW=${srk_dec_pw} -DSRK_DEC_SALT=${srk_dec_salt}"
+CFLAGS:append = " -DSRK_DEC_PW=${srk_dec_pw} -DSRK_DEC_SALT=${srk_dec_salt}"

# Uncomment below line if using the plain srk password for development
-#CFLAGS_append += "-DTPM_SRK_PLAIN_PW"
+#CFLAGS:append = " -DTPM_SRK_PLAIN_PW"

do_configure:prepend() {
cd ${B}



Re: [meta-security][PATCH] apparmor: fix warning of remove operator combined with +=

Armin Kuster
 

On 11/18/21 11:06 PM, kai wrote:
From: Kai Kang <kai.kang@windriver.com>

Fix warning for apparmor:

| WARNING: /path/to/meta-security/recipes-mac/AppArmor/apparmor_3.0.1.bb:
| RDEPENDS:${PN}:remove += is not a recommended operator combination,
| please replace it.
thanks,
merged.


Signed-off-by: Kai Kang <kai.kang@windriver.com>
---
recipes-mac/AppArmor/apparmor_3.0.1.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-mac/AppArmor/apparmor_3.0.1.bb b/recipes-mac/AppArmor/apparmor_3.0.1.bb
index 389e72a..818be15 100644
--- a/recipes-mac/AppArmor/apparmor_3.0.1.bb
+++ b/recipes-mac/AppArmor/apparmor_3.0.1.bb
@@ -168,7 +168,7 @@ RDEPENDS:${PN}:libc-glibc += "glibc-utils"

# Add coreutils and findutils only if sysvinit scripts are in use
RDEPENDS:${PN} += "${@["coreutils findutils", ""][(d.getVar('VIRTUAL-RUNTIME_init_manager') == 'systemd')]} ${@bb.utils.contains('PACKAGECONFIG','python','python3-core python3-modules','', d)}"
-RDEPENDS:${PN}:remove += "${@bb.utils.contains('PACKAGECONFIG','perl','','perl', d)}"
+RDEPENDS:${PN}:remove = "${@bb.utils.contains('PACKAGECONFIG','perl','','perl', d)}"
RDEPENDS:${PN}-ptest += "perl coreutils dbus-lib bash"

INSANE_SKIP:${PN} = "ldflags"



[meta-security][PATCH] libest: does not build with openssl 3.x

Armin Kuster
 

blacklist for now. Remove from pkg grp

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
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


OpenEmbedded Happy Hour December 3 8pm/2000 UTC after OEDVM

Denys Dmytriyenko
 

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@denix.org>
PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964
Fingerprint: 25FC E4A5 8A72 2F69 1186 6D76 4209 0272 9A92 C964


Re: [meta-rockchip] dunfell: u-boot build issue when added patch to u-boot

Marek Belisko
 

Hi,

On Fri, Nov 26, 2021 at 11:55 PM Trevor Woerner <twoerner@gmail.com> 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


Re: [OE-core] How to create connman_1.40.bbappend to enable and to build connman with iwd?

JH
 

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



On Thu, Nov 25, 2021 at 10:26 PM JH <jupiter.hce@gmail.com> 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@lists.yoctoproject.org> 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


Re: [OE-core] How to create connman_1.40.bbappend to enable and to build connman with iwd?

Tim Orling
 



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:
I don’t have any advice for building it however.


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







Re: [OE-core] How to create connman_1.40.bbappend to enable and to build connman with iwd?

Tim Orling
 



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:
I don’t have any advice for building it however.


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




Re: [meta-rockchip] dunfell: u-boot build issue when added patch to u-boot

Trevor Woerner
 

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


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

Armin Kuster
 

merged.

On 11/16/21 10:28 AM, Jeremy A. Puhlman wrote:
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.

JP: Updated for version differences.

Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
(cherry picked from commit e81c15f851ca5396c78c8737967ee38db0ebe0cd)
Signed-off-by: Jeremy A. Puhlman <jpuhlman@mvista.com>
---
recipes-security/sssd/sssd_1.16.5.bb | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/recipes-security/sssd/sssd_1.16.5.bb b/recipes-security/sssd/sssd_1.16.5.bb
index 02d0837..f13fc49 100644
--- a/recipes-security/sssd/sssd_1.16.5.bb
+++ b/recipes-security/sssd/sssd_1.16.5.bb
@@ -120,10 +120,17 @@ 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 dbus libldb libpam"
+PACKAGES =+ "libsss-sudo libsss-autofs"
+ALLOW_EMPTY_libsss-sudo = "1"
+ALLOW_EMPTY_libsss-autofs = "1"
+
+FILES_${PN}-dev += "${libdir}/sssd/modules/lib*.so"
+FILES_${PN} += "${base_libdir}/security/pam_sss*.so \
+ ${datadir}/dbus-1/system-services/*.service \
+ ${libdir}/krb5/* \
+ ${libdir}/ldb/* \
+ "
+FILES_libsss-autofs = "${libdir}/sssd/modules/libsss_autofs.so"
+FILES_libsss-sudo = "${libdir}/libsss_sudo.so"
+
+RDEPENDS_${PN} = "bind dbus libldb libpam libsss-sudo libsss-autofs"


How to create connman_1.40.bbappend to enable and to build connman with iwd?

JH
 

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@lists.yoctoproject.org> 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

1661 - 1680 of 57064