Date   

Let me tell you how I really feel. Zero filter. If you need meta-python2, you need to become a maintainer. Immediately. Period.

Tim Orling
 

I have absolutely no need for python2, I made this abundantly clear when I created the meta-python2 layer.

If you depend upon continuing support of python2 via the meta-python2 layer, this is your call to arms.

I was originally intending to abdicate any support after the 3.1 "dunfell" release, but managed to somehow continue supporting it into the crest of the 3.2 "gatesgarth" release.

I will stop all support and actively refuse lo respond to any emails and this layer will be dead and I have zero care in the world that it stops being useful. I do not use it. I do not depend upon it. You are not paying me to do this. You cannot pay me enough to do this. Period. Support yourself.

If this is not clear enough, I am happy to have a virtual video call with you that you will not like.

--moto-timo


Re: Using RDEPENDS in bbappend files to install additional packages?

Chuck Wolber
 

Apologies for the marginally related reply, but the provided example triggered a reminder of a best practice we started doing that had some significant maintainability benefits.

Instead of this pattern:

RDEPENDS_${PN} += " \
         lighttpd-module-alias \
         lighttpd-module-auth \
         lighttpd-module-cgi \
         lighttpd-module-compress \
         lighttpd-module-evasive \
         lighttpd-module-evhost \


We found that this pattern made it significantly easier to manage recipes, as well as use common command line tools like grep/sed/awk, without having to deal with the complexities of multi-line processing. It also helped make git commits and patches much more focused and readable.

RDEPENDS_${PN} += " lighttpd-module-alias"
RDEPENDS_${PN} += " lighttpd-module-auth"
RDEPENDS_${PN} += " lighttpd-module-cgi"
RDEPENDS_${PN} += " lighttpd-module-compress"
RDEPENDS_${PN} += " lighttpd-module-evasive"
RDEPENDS_${PN} += " lighttpd-module-evhost"

..Ch:W..


On Mon, Oct 19, 2020 at 6:12 AM Quentin Schulz <quentin.schulz@...> wrote:
Hi Robert,

On Mon, Oct 19, 2020 at 09:06:39AM -0400, Robert P. J. Day wrote:
> Another question regarding recipe/coding style (based on actual
> examples I run across in existing code bases).
>
> In one vendor's layer, in file "lighttpd_1.4.%.bbappend", I read:
>
>   RDEPENDS_${PN} += " \
>         lighttpd-module-alias \
>         lighttpd-module-auth \
>         lighttpd-module-cgi \
>         lighttpd-module-compress \
>         lighttpd-module-evasive \
>         lighttpd-module-evhost \
>         ... sizable snip of many ore modules ...
>
> There's little question that this is being used to incorporate a
> number of optional modules into the final image, but I'm assuming
> that this is really not the recommended way to do it.
>
> The YP reference manual defines RDEPENDS as identifying "other
> packages that must be installed in order for the package to function
> correctly," which suggests that it's the base recipe that should
> define actual runtime dependencies.
>
> I would have thought that the natural way to do the above would
> be to either use IMAGE_INSTALL_append or (my preference) define
> a packagegroup that includes all those packages, then simply
> include the packagegroup.
>
> In short, am I reasonable in assuming that bbappend files should
> not (ab)use RDEPENDS in the above way?
>

I'd say they either should be added to IMAGE_INSTALL one by one, or
being put into a packagegroup or even use RRECOMMENDS instead of
RDEPENDS. To me, it feels wrong too, if it's really not a need, they
should not be in RDEPENDS.

Quentin





--
"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire


Re: [meta-zephyr][PATCH] zephyr: use TCLIBC=newlib directly

Khem Raj
 

On 10/20/20 5:42 AM, Ross Burton wrote:
Instead of setting TCLIBC=baremetal and then adding newlib in various places,
just set TCLIBC=newlib directly.
This also means we can use the standard DEPENDS instead of reinventing them.
I think this will also link the app with newlib now which previously was using baremetal.

Signed-off-by: Ross Burton <ross.burton@...>
---
conf/distro/zephyr.conf | 7 +------
recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc | 3 ---
2 files changed, 1 insertion(+), 9 deletions(-)
diff --git a/conf/distro/zephyr.conf b/conf/distro/zephyr.conf
index 44448af..a98da32 100644
--- a/conf/distro/zephyr.conf
+++ b/conf/distro/zephyr.conf
@@ -5,16 +5,11 @@ DISTRO_VERSION = "1.0"
TARGET_VENDOR = "-yocto"
-TCLIBC = "baremetal"
-TCLIBCAPPEND = ""
+TCLIBC = "newlib"
TEST_TARGET = "QemuTargetZephyr"
TEST_SUITES = "zephyr"
-PREFERRED_PROVIDER_virtual/libc = "newlib"
-PREFERRED_PROVIDER_virtual/libiconv = "newlib"
-
-TOOLCHAIN_TARGET_TASK += " newlib"
INHERIT += "siteinfo-zephyr"
INHERIT += "uninative"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
index 7fa4b25..b947472 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
@@ -19,9 +19,6 @@ EXTRA_OECMAKE_append_arm = " -DZEPHYR_MODULES=${S}/modules/cmsis"
export ZEPHYR_BASE="${S}"
-# We always need a toolchain to cross-compile.
-INHIBIT_DEFAULT_DEPS = "1"
-DEPENDS += "gcc-cross-${TARGET_ARCH} libgcc ${TOOLCHAIN_TARGET_TASK} gperf-native"
DEPENDS += " python3-pyelftools-native python3-pyyaml-native python3-pykwalify-native"
CROSS_COMPILE = "${STAGING_BINDIR_TOOLCHAIN}/${TARGET_PREFIX}"


Re: [meta-zephyr][PATCH] README: add patch submission details

Khem Raj
 

On 10/20/20 3:04 AM, Ross Burton wrote:
---
README.txt | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/README.txt b/README.txt
index be1ea39..a02659a 100644
--- a/README.txt
+++ b/README.txt
Can we use markdown syntax and call it README.md ? this helps with
other infras like gitlab and github where this might be cloned to

@@ -69,4 +69,15 @@ or
$ MACHINE=qemu-nios2 bitbake zephyr-kernel-test-all -ctestimage
+Contributing
+============
+Patches for meta-zephyr should be sent to the yocto@...
+mailing list. See https://lists.yoctoproject.org/g/yocto for subscription
+details and the list archive. Please add [meta-zephyr] to the subject so
+the patches are identifable.
+
+Git can be configured to send mails appropriately when using git send-email:
+
+$ git config --local sendemail.to yocto@...
+$ git config --local format.subjectPrefix meta-zephy][PATCH


QA notification for completed autobuilder build (yocto-3.2.rc1)

pokybuild@...
 

A build flagged for QA (yocto-3.2.rc1) was completed on the autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.2.rc1


Build hash information:

bitbake: 9345d257ced432adc2d16af20ace58cc7c086aab
meta-arm: b419151acd2761d0e2723f0d0c0bbbed00c45c5b
meta-gplv2: 6e8e969590a22a729db1ff342de57f2fd5d02d43
meta-intel: 0e4b3cb01735bdc5ebf50c547927f1f59b0248d2
meta-kernel: dbf8bdfa6683404e5071feb47ef6aa347cab1b01
meta-mingw: d2809d7c93bdb46014e1f8b3b0a4f42030078905
oecore: ea8ba9a15bcec7f5fbce1f40170298f87a808249
poky: 4e4a302e37ac06543e9983773cdb4caf7728330d



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...


[meta-selinux][PATCH] conf/layer.conf: Bump to gatesgarth

Anibal Limon
 

Signed-off-by: Aníbal Limón <anibal.limon@...>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index da24359..669e066 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -23,7 +23,7 @@ BBFILE_PRIORITY_selinux = "5"
# cause compatibility issues with other layers
LAYERVERSION_selinux = "1"

-LAYERSERIES_COMPAT_selinux = "dunfell"
+LAYERSERIES_COMPAT_selinux = "gatesgarth"

LAYERDEPENDS_selinux = " \
core \
--
2.28.0


Yocto Project Status WW42'20

Stephen Jolley
 

Current Dev Position: YP 3.2 Final Build

Next Deadline: YP 3.2 M4 Feature Freeze - Now

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.2 rc1 is currently building on the autobuilder.
  • Unfortunately, intermittent autobuilder issues continue to occur, we had a record 8 of them in one full build over the weekend. We’re now holding out hope that better debugging data (such as qemu monitor information) when issues occur will help identify several of the issues. You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

Help with any of these would be much appreciated, unfortunately it is proving hard to find anyone interested in helping figure these out and they significantly hamper our testing.

  • We have a steadily riding WDD and Medium+ bug count which is a concern.
  • We realized there was an issue with wiki account creation. These should be created now but please report if there are any issues.
  • A YP 3.3 planning document has been created for ideas about what may happen in the YP 3.3 release (assuming there are people to work on the items):

https://docs.google.com/document/d/1IHiE0NU0XspDocgxZeLQ_W7o-yr0nVeBjbqImQUtH5A/edit Request suggest or edit access if you want to add to it.

  • The above document has the proposed dates for YP 3.3 milestones and release.

 

Ways to contribute:

 

YP 3.2 Milestone Dates:

  • YP 3.2 M4 building now.
  • YP 3.2 M4 Release date 2020/10/30

 

Planned upcoming dot releases:

  • YP 3.1.4 build date 2020/11/2
  • YP 3.1.4 release date 2020/11/13

 

Tracking Metrics:

 

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Re: dnf error coming while compiling core-image-sato image.

Randy MacLeod
 

On 2020-10-20 9:06 a.m., NIKHIL PATIL wrote:
I changed in local.conf (ostree related stuffs ), and put it for compilation , that time i got these error
Hi Nikhil,

We encourage people to avoid top-posting so that discussions are
easier to read:

https://wiki.yoctoproject.org/wiki/Community_Guidelines#Mailing_List_Guidelines

Your description doesn't enable anyone else to reproduce what you are
doing. What git repos (oe-core/poky/bitbake/...) are you using and
what commit is at the HEAD of each?

You have no doubt sourced the oe-init-build-env file, otherwise bitbake
wouldn't work. Can you do that again and send either your full
conf/local.conf file or the lines that you added.


You might read:
https://wiki.yoctoproject.org/wiki/Bug_reporting_and_Information_levels
It's aimed at people opening bugs in the YP Bugzilla but the same rules
apply to email asking for help.

On Tue, Oct 20, 2020 at 6:49 AM Randy MacLeod <randy.macleod@... <mailto:randy.macleod@...>> wrote:
On 2020-10-18 6:41 a.m., NIKHIL PATIL wrote:
> Hi team ,
>        I am getting continuously dnf error, How we can
resolve these .
Hi Nikhil,
What exact steps did you take before getting this error and
what build host are you using?
Are you able to build core-image-minimal using oe-core/master
and the default local.conf for qemux86-64?
Please confirm that you are able to build core-image-minimal so
that people understand your level of experience when trying to help you.

../Randy

../Randy

>
> core-image-sato-1.0-r0 do_rootfs: Could not invoke dnf. Command
>
'/data/pradeep/inti_dmsv/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/recipe-sysroot-native/usr/bin/dnf

> -y -c
>
/data/pradeep/inti_dmsv/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/rootfs/etc/dnf/dnf.conf

>
--setopt=reposdir=/data/pradeep/inti_dmsv/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/rootfs/etc/yum.repos.d

>
--repofrompath=oe-repo,/data/pradeep/inti_dmsv/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/oe-rootfs-repo

>
--installroot=/data/pradeep/inti_dmsv/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/rootfs

>
--setopt=logdir=/data/pradeep/inti_dmsv/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/temp

> -x packagegroup-core-apl-extra --nogpgcheck install
autoconf-archive dnf
> gstreamer1.0-vaapi iqvlinux jhi kernel-modules libtcti-device0
> libtcti-device-dev libtcti-device-staticdev libtcti-socket0
> libtcti-socket-dev libtcti-socket-staticdev libsapi0 libsapi-dev
> libsapi-staticdev libva mesa-glxinfo libmraa1 nodejs
> packagegroup-base-extended packagegroup-core-audio-essential
> packagegroup-core-boot packagegroup-core-buildessential-extended
> packagegroup-core-graphics-essential packagegroup-core-ssh-dropbear
> packagegroup-core-tools-testapps packagegroup-core-x11-base
> packagegroup-core-x11-sato psplash rpm run-postinsts swig tpm2-abrmd
> usb-modeswitch usb-modeswitch-data va-intel wayland weston
> weston-examples xinit-env xserver-xorg locale-base-en-us
> locale-base-en-gb' returned 1:
> Added oe-repo repo from
>
/data/pradeep/inti_dmsv/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/oe-rootfs-repo
>
>
>
>
--
# Randy MacLeod
# Wind River Linux

--
# Randy MacLeod
# Wind River Linux


Re: network-manager #nmcli #yocto

Quentin Schulz
 

On Tue, Oct 20, 2020 at 06:51:33AM -0700, Zoltan Kerenyi Nagy wrote:
* I hope this is gona be public *
It is, you just answered the wrong mail so my answer isn't in the body
of this mail.

I did a diff between your recommended file, and mine, there is no diff, since it's from the same source.
I understand that I had to install network-manager-nmcli, but how? In the do_install_append() function??
You don't need to change anything in the networkmanager recipe. You need
to add networkmanager-nmcli to the packages installed in your image and
that is done in your image recipe by usually adding it to IMAGE_INSTALL.

I can recommend the videos from our YoctoProject Youtube channel to get
started on Yocto: https://www.youtube.com/watch?v=ThTl4FItfMI&list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj

We also have great docs at: https://docs.yoctoproject.org.

Cheers,
Quentin


Re: network-manager #nmcli #yocto

Zoltan Kerenyi Nagy
 

* I hope this is gona be public *

I did a diff between your recommended file, and mine, there is no diff, since it's from the same source.
I understand that I had to install network-manager-nmcli, but how? In the do_install_append() function??


Re: dnf error coming while compiling core-image-sato image.

NIKHIL PATIL
 

I changed in local.conf (ostree related stuffs ), and put it for compilation , that time i got these error 


On Tue, Oct 20, 2020 at 6:49 AM Randy MacLeod <randy.macleod@...> wrote:
On 2020-10-18 6:41 a.m., NIKHIL PATIL wrote:
> Hi team ,
>        I am getting continuously dnf error, How we can resolve these .

Hi Nikhil,

What exact steps did you take before getting this error and
what build host are you using?

Are you able to build core-image-minimal using oe-core/master
and the default local.conf for qemux86-64?

../Randy

>
> core-image-sato-1.0-r0 do_rootfs: Could not invoke dnf. Command
> '/data/pradeep/inti_dmsv/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/recipe-sysroot-native/usr/bin/dnf
> -y -c
> /data/pradeep/inti_dmsv/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/rootfs/etc/dnf/dnf.conf
> --setopt=reposdir=/data/pradeep/inti_dmsv/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/rootfs/etc/yum.repos.d
> --repofrompath=oe-repo,/data/pradeep/inti_dmsv/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/oe-rootfs-repo
> --installroot=/data/pradeep/inti_dmsv/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/rootfs
> --setopt=logdir=/data/pradeep/inti_dmsv/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/temp
> -x packagegroup-core-apl-extra --nogpgcheck install autoconf-archive dnf
> gstreamer1.0-vaapi iqvlinux jhi kernel-modules libtcti-device0
> libtcti-device-dev libtcti-device-staticdev libtcti-socket0
> libtcti-socket-dev libtcti-socket-staticdev libsapi0 libsapi-dev
> libsapi-staticdev libva mesa-glxinfo libmraa1 nodejs
> packagegroup-base-extended packagegroup-core-audio-essential
> packagegroup-core-boot packagegroup-core-buildessential-extended
> packagegroup-core-graphics-essential packagegroup-core-ssh-dropbear
> packagegroup-core-tools-testapps packagegroup-core-x11-base
> packagegroup-core-x11-sato psplash rpm run-postinsts swig tpm2-abrmd
> usb-modeswitch usb-modeswitch-data va-intel wayland weston
> weston-examples xinit-env xserver-xorg locale-base-en-us
> locale-base-en-gb' returned 1:
> Added oe-repo repo from
> /data/pradeep/inti_dmsv/yocto_build/build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/oe-rootfs-repo
>
>
>
>
>


--
# Randy MacLeod
# Wind River Linux


Re: [meta-zephyr][PATCH] zephyr: use TCLIBC=newlib directly

Ross Burton
 

Please do review this one carefully, it continues to build for me and
solves a build failure when using meta-zephyr but not DISTRO=zephyr
(instead, a custom DISTRO and a MACHINE that sets TCLIBC=newlib) but
obviously it is rooting around the build depends and I didn't test the
SDK pieces.

Ross

On Tue, 20 Oct 2020 at 13:43, Ross Burton via lists.yoctoproject.org
<ross=burtonini.com@...> wrote:

Instead of setting TCLIBC=baremetal and then adding newlib in various places,
just set TCLIBC=newlib directly.

This also means we can use the standard DEPENDS instead of reinventing them.

Signed-off-by: Ross Burton <ross.burton@...>
---
conf/distro/zephyr.conf | 7 +------
recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc | 3 ---
2 files changed, 1 insertion(+), 9 deletions(-)

diff --git a/conf/distro/zephyr.conf b/conf/distro/zephyr.conf
index 44448af..a98da32 100644
--- a/conf/distro/zephyr.conf
+++ b/conf/distro/zephyr.conf
@@ -5,16 +5,11 @@ DISTRO_VERSION = "1.0"

TARGET_VENDOR = "-yocto"

-TCLIBC = "baremetal"
-TCLIBCAPPEND = ""
+TCLIBC = "newlib"

TEST_TARGET = "QemuTargetZephyr"
TEST_SUITES = "zephyr"

-PREFERRED_PROVIDER_virtual/libc = "newlib"
-PREFERRED_PROVIDER_virtual/libiconv = "newlib"
-
-TOOLCHAIN_TARGET_TASK += " newlib"
INHERIT += "siteinfo-zephyr"

INHERIT += "uninative"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
index 7fa4b25..b947472 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
@@ -19,9 +19,6 @@ EXTRA_OECMAKE_append_arm = " -DZEPHYR_MODULES=${S}/modules/cmsis"
export ZEPHYR_BASE="${S}"


-# We always need a toolchain to cross-compile.
-INHIBIT_DEFAULT_DEPS = "1"
-DEPENDS += "gcc-cross-${TARGET_ARCH} libgcc ${TOOLCHAIN_TARGET_TASK} gperf-native"
DEPENDS += " python3-pyelftools-native python3-pyyaml-native python3-pykwalify-native"
CROSS_COMPILE = "${STAGING_BINDIR_TOOLCHAIN}/${TARGET_PREFIX}"

--
2.25.1




[meta-zephyr][PATCH] zephyr: use TCLIBC=newlib directly

Ross Burton
 

Instead of setting TCLIBC=3Dbaremetal and then adding newlib in various p=
laces,
just set TCLIBC=3Dnewlib directly.

This also means we can use the standard DEPENDS instead of reinventing th=
em.

Signed-off-by: Ross Burton <ross.burton@...>
---
conf/distro/zephyr.conf | 7 +------
recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc | 3 ---
2 files changed, 1 insertion(+), 9 deletions(-)

diff --git a/conf/distro/zephyr.conf b/conf/distro/zephyr.conf
index 44448af..a98da32 100644
--- a/conf/distro/zephyr.conf
+++ b/conf/distro/zephyr.conf
@@ -5,16 +5,11 @@ DISTRO_VERSION =3D "1.0"
=20
TARGET_VENDOR =3D "-yocto"
=20
-TCLIBC =3D "baremetal"
-TCLIBCAPPEND =3D ""
+TCLIBC =3D "newlib"
=20
TEST_TARGET =3D "QemuTargetZephyr"
TEST_SUITES =3D "zephyr"
=20
-PREFERRED_PROVIDER_virtual/libc =3D "newlib"
-PREFERRED_PROVIDER_virtual/libiconv =3D "newlib"
-
-TOOLCHAIN_TARGET_TASK +=3D " newlib"
INHERIT +=3D "siteinfo-zephyr"
=20
INHERIT +=3D "uninative"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc b/reci=
pes-kernel/zephyr-kernel/zephyr-kernel-common.inc
index 7fa4b25..b947472 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
@@ -19,9 +19,6 @@ EXTRA_OECMAKE_append_arm =3D " -DZEPHYR_MODULES=3D${S}/=
modules/cmsis"
export ZEPHYR_BASE=3D"${S}"
=20
=20
-# We always need a toolchain to cross-compile.
-INHIBIT_DEFAULT_DEPS =3D "1"
-DEPENDS +=3D "gcc-cross-${TARGET_ARCH} libgcc ${TOOLCHAIN_TARGET_TASK} g=
perf-native"
DEPENDS +=3D " python3-pyelftools-native python3-pyyaml-native python3-p=
ykwalify-native"
CROSS_COMPILE =3D "${STAGING_BINDIR_TOOLCHAIN}/${TARGET_PREFIX}"
=20
--=20
2.25.1


[meta-zephyr][PATCH] README: add patch submission details

Ross Burton
 

---
README.txt | 11 +++++++++++
1 file changed, 11 insertions(+)

diff --git a/README.txt b/README.txt
index be1ea39..a02659a 100644
--- a/README.txt
+++ b/README.txt
@@ -69,4 +69,15 @@ or
$ MACHINE=3Dqemu-nios2 bitbake zephyr-kernel-test-all -ctestimage
=20
=20
+Contributing
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
+Patches for meta-zephyr should be sent to the yocto@...=
rg
+mailing list. See https://lists.yoctoproject.org/g/yocto for subscripti=
on
+details and the list archive. Please add [meta-zephyr] to the subject s=
o
+the patches are identifable.
+
+Git can be configured to send mails appropriately when using git send-em=
ail:
+
+$ git config --local sendemail.to yocto@...
+$ git config --local format.subjectPrefix meta-zephy][PATCH
--=20
2.25.1


Re: Private: Re: [yocto] network-manager #yocto #nmcli

Quentin Schulz
 

Please keep the mailing list in copy so everyone can benefit from your
progress/the solution, thanks!

On Tue, Oct 20, 2020 at 02:55:26AM -0700, Zoltan Kerenyi Nagy wrote:
I'll do this, thanks.

Interestingly there is a line in the recipe file, which suggests that nmtui will be included.
-with-nmtui=yes \
This is an option at build time (i.e. for the **recipe**). It just
configures the piece of SW you're trying to build.

A bitbaked recipe's outcome is **packages**. In **most** cases, the main
package is named after the recipe (which is usually a source of
confusion for people). However, to slim down the main package, most
recipes split their output into multiple packages.

In your case, networkmanager is configured to be compiled with nmtui
support. However, the recipe is asked to put the resulting
binaries/conf files/libs into a separate package (called
networkmanager-nmtui).

When you're installing networmanager, you're not installing the whole
outcome of networkmanager recipe (nor the recipe itself) but the main
package that is the outcome of said recipe. It might not contain all you
want, hence the need for installing other packages for enabling all
features you want/need.

Hope this helps,
Quentin


[meta-zephyr][PATCH] layer.conf: add layer dependency on meta-python

Ross Burton
 

Signed-off-by: Ross Burton <ross.burton@...>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 4ecd6a2..f9de654 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -13,6 +13,6 @@ BBFILE_PRIORITY_zephyr =3D "6"
# cause compatibility issues with other layers
LAYERVERSION_zephyr =3D "1"
=20
-LAYERDEPENDS_zephyr =3D "core"
+LAYERDEPENDS_zephyr =3D "core meta-python"
=20
LAYERSERIES_COMPAT_zephyr =3D "dunfell gatesgarth"
--=20
2.25.1


Re: Generating non-rootfs file system images as update artifacts for multi-partition image updates

Stefano Babic
 

Hi Martin,

On 20.10.20 11:00, Martin Hundebøll wrote:
Hi Stefano,

On 19/10/2020 18.23, Stefano Babic wrote:
Hi Enrico,

On 19.10.20 17:43, Enrico J?rns wrote:
Hi,

as I did not have much success with my question in the OR irc, let's
try it here in a more verbose way. ;)

Imagine I have an A+B redundant boot system, with additional bootloader
and separate home or application file system. Thus my layout would be
like:

p1: bootloader
p2: rootfs A
p3: rootfs B
p4: appfs A
p5: appfs B

where rootfs A + appfs A form a logical unit with respect to the image-
based update handling.

No my question is: How do I generate the images required for the
bootloader partition and/or the appfs partition with the OE standard
image generation mechanisms?

We have a working solution with the 'genimage' tool for quite some
time, but I wonder if that could be done with the more tightly
integrated wic, too.


To my understanding, the way of creating something like a bootloader
image or an application file system is by using wic's image split
capabilities and doing (non-redundant example):

part /boot --source rootfs (or some plugin)
part / ... --source rootfs
part /app  --source rootfs
I had the same use case as you, and I could use something like

part /app --source rawcopy --sourceparams="file=..."

and the file points to the image I want to put on the partition.


This will create multiple file system images out of the prior monolitic
rootfs one. It also does all necessary changes for mounting, like
modifying the rootfs /etc/fstab etc.
Thus, using these generated images in my update scenario would be the
way to go for me.


BUT, currently I do not see any straight-forward way of how to use
them. One could add them to what the image_wic* image fstypes generate,
but this will violate the default rule that each image fstype generates
exactly one image.
And the generated images are a little hard to reference as one cannot
give them names (which is probably a negligable issue) and they do not
have a fstype extension.
The more sever issue is that I would also like to have archives (like
tar.bz2) of the content of /app or /boot as I can use them quite good
for installing to partitions whose size and other parameters I do not
know very beforehand (also applicable to UBI volumes).

But, at the moment there does not seem to be a designated way of doing
something like I intended. I wonder how others solve the generation of
non-rootfs images with YP/OE?

Or did I miss something that already exists for this?
I have not a straightforward solution. I inherited just "image" and I
cleaned up at the end with a ROOTFS_POSTPROCESS_COMMAND what was
superfluous. Maybe forcing packagegroup-core-boot can be an option.
Yeah, this is also what I often end up doing. I often need a way to
bundle several artifacts together, i.e. bootloader, rootfs, sdk, etc.

With that in mind, I would also very much like a way to make image
artifacts available in WORKDIR without pulling from DEPLOY_DIR_IMAGE -
it just feels wrong to use files from the output folder as input in recipe.
...but as Enrico already said (and I agree with him), this is quite a
"hacking" way to do it. Anyway, I would prefer a clean way in this
direction instead of generating a wic just to extract artifacts (but
again, this is just another way to reach the goal, probably it is just a
question of taste). This could be maybe reachable introducing a more
"base" class for image (or one inheriting just from image ) and make
sure that no packages are implicitely (ok, this means to force
RDEPENDS..) installed.

Regards,
Stefano


--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@...
=====================================================================


Re: Generating non-rootfs file system images as update artifacts for multi-partition image updates

Martin Hundeb?ll
 

Hi Stefano,

On 19/10/2020 18.23, Stefano Babic wrote:
Hi Enrico,
On 19.10.20 17:43, Enrico J?rns wrote:
Hi,

as I did not have much success with my question in the OR irc, let's
try it here in a more verbose way. ;)

Imagine I have an A+B redundant boot system, with additional bootloader
and separate home or application file system. Thus my layout would be
like:

p1: bootloader
p2: rootfs A
p3: rootfs B
p4: appfs A
p5: appfs B

where rootfs A + appfs A form a logical unit with respect to the image-
based update handling.

No my question is: How do I generate the images required for the
bootloader partition and/or the appfs partition with the OE standard
image generation mechanisms?

We have a working solution with the 'genimage' tool for quite some
time, but I wonder if that could be done with the more tightly
integrated wic, too.


To my understanding, the way of creating something like a bootloader
image or an application file system is by using wic's image split
capabilities and doing (non-redundant example):

part /boot --source rootfs (or some plugin)
part / ... --source rootfs
part /app --source rootfs
I had the same use case as you, and I could use something like
part /app --source rawcopy --sourceparams="file=..."
and the file points to the image I want to put on the partition.


This will create multiple file system images out of the prior monolitic
rootfs one. It also does all necessary changes for mounting, like
modifying the rootfs /etc/fstab etc.
Thus, using these generated images in my update scenario would be the
way to go for me.


BUT, currently I do not see any straight-forward way of how to use
them. One could add them to what the image_wic* image fstypes generate,
but this will violate the default rule that each image fstype generates
exactly one image.
And the generated images are a little hard to reference as one cannot
give them names (which is probably a negligable issue) and they do not
have a fstype extension.
The more sever issue is that I would also like to have archives (like
tar.bz2) of the content of /app or /boot as I can use them quite good
for installing to partitions whose size and other parameters I do not
know very beforehand (also applicable to UBI volumes).

But, at the moment there does not seem to be a designated way of doing
something like I intended. I wonder how others solve the generation of
non-rootfs images with YP/OE?

Or did I miss something that already exists for this?
I have not a straightforward solution. I inherited just "image" and I
cleaned up at the end with a ROOTFS_POSTPROCESS_COMMAND what was
superfluous. Maybe forcing packagegroup-core-boot can be an option.
Yeah, this is also what I often end up doing. I often need a way to bundle several artifacts together, i.e. bootloader, rootfs, sdk, etc.

With that in mind, I would also very much like a way to make image artifacts available in WORKDIR without pulling from DEPLOY_DIR_IMAGE - it just feels wrong to use files from the output folder as input in recipe.

// Martin


Re: network-manager #nmcli #yocto

Quentin Schulz
 

Hi,

On Tue, Oct 20, 2020 at 01:48:37AM -0700, Zoltan Kerenyi Nagy wrote:
Hi All,

My board is a Barix Ipam400, and I'd like to add 4G conenction to it via a USB and 4G Dongle. The dongle is a Huewei E3372 stick.
I'd spent some time with wvdial and usbmodeswitch with no success. Then I tried the stick in my laptop with network-manager, it was working like a charm
Then I've found this ( https://github.com/openembedded/meta-openembedded/tree/master/meta-networking/recipes-connectivity/networkmanager/networkmanager ) source, since the original recipe file would not compile.

Ive bitbaked network.manager loaded to the hardware however there is no nmcli and nmtoi included.
You need to bitbake networkmanager but install networkmanager-nmcli
and/or networkmanager-nmtui, c.f.
http://cgit.openembedded.org/meta-openembedded/tree/meta-networking/recipes-connectivity/networkmanager/networkmanager_1.22.14.bb?h=master#n89

I'd probably triple check all the PACKAGECONFIG you need are set:
http://cgit.openembedded.org/meta-openembedded/tree/meta-networking/recipes-connectivity/networkmanager/networkmanager_1.22.14.bb?h=master#n65

Since you want 4G, it might be a good idea to have modemmanager enabled?
I've never used networmanager so can't help much more than that.

Quentin


Re: Generating non-rootfs file system images as update artifacts for multi-partition image updates

Martin Hundeb?ll
 

Hi Enrico,

On 19/10/2020 17.43, Enrico J?rns wrote:
Hi,
as I did not have much success with my question in the OR irc, let's
try it here in a more verbose way. ;)
Imagine I have an A+B redundant boot system, with additional bootloader
and separate home or application file system. Thus my layout would be
like:
p1: bootloader
p2: rootfs A
p3: rootfs B
p4: appfs A
p5: appfs B
where rootfs A + appfs A form a logical unit with respect to the image-
based update handling.
No my question is: How do I generate the images required for the
bootloader partition and/or the appfs partition with the OE standard
image generation mechanisms?
We have a working solution with the 'genimage' tool for quite some
time, but I wonder if that could be done with the more tightly
integrated wic, too.
To my understanding, the way of creating something like a bootloader
image or an application file system is by using wic's image split
capabilities and doing (non-redundant example):
part /boot --source rootfs (or some plugin)
part / ... --source rootfs
part /app --source rootfs
This will create multiple file system images out of the prior monolitic
rootfs one. It also does all necessary changes for mounting, like
modifying the rootfs /etc/fstab etc.
Thus, using these generated images in my update scenario would be the
way to go for me.
BUT, currently I do not see any straight-forward way of how to use
them. One could add them to what the image_wic* image fstypes generate,
but this will violate the default rule that each image fstype generates
exactly one image.
And the generated images are a little hard to reference as one cannot
give them names (which is probably a negligable issue) and they do not
have a fstype extension.
The more sever issue is that I would also like to have archives (like
tar.bz2) of the content of /app or /boot as I can use them quite good
for installing to partitions whose size and other parameters I do not
know very beforehand (also applicable to UBI volumes).
But, at the moment there does not seem to be a designated way of doing
something like I intended. I wonder how others solve the generation of
non-rootfs images with YP/OE?
I've often needed similar functionality.

Sometimes I wonder if one could make a recipe/class that depends on the rootfs contents, installs some packages, and packages the resulting differences - maybe using the --exclude option to tar?

// Martin