Date   

[meta-cgl][PATCH] heartbeat: don't use trailing slash in S

Yu, Mingli
 

From: Mingli Yu <mingli.yu@windriver.com>

* see oe-core base.bbclass changes from:
https://lists.openembedded.org/g/openembedded-core/message/143159
https://lists.openembedded.org/g/openembedded-core/message/143161

Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
---
meta-cgl-common/recipes-cgl/heartbeat/heartbeat_3.0.6.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-cgl-common/recipes-cgl/heartbeat/heartbeat_3.0.6.bb b/meta-cgl-common/recipes-cgl/heartbeat/heartbeat_3.0.6.bb
index 35fee43..5031c64 100644
--- a/meta-cgl-common/recipes-cgl/heartbeat/heartbeat_3.0.6.bb
+++ b/meta-cgl-common/recipes-cgl/heartbeat/heartbeat_3.0.6.bb
@@ -38,7 +38,7 @@ SRC_URI = " \
"
SRC_URI[md5sum] = "101c8f507b1f407468d5ef15ae6719da"
SRC_URI[sha256sum] = "851d2add2c129fef9fede764fec80229e1f6e7295e0e979950d10258648b462c"
-S = "${WORKDIR}/Heartbeat-3-0-958e11be8686/"
+S = "${WORKDIR}/Heartbeat-3-0-958e11be8686"
DEPENDS = "cluster-glue corosync gnutls libxslt-native xmlto-native docbook-xml-dtd4-native docbook-xsl-stylesheets-native intltool"
RDEPENDS_${PN} += "python"
inherit autotools-brokensep pkgconfig useradd
--
2.17.1


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

Naveen Saini
 

Few kernel testcases have dependencies on gperf-native, so we should keep it in DEPENDS.

Regards,
Naveen

-----Original Message-----
From: Ross Burton <ross.burton@arm.com>
Sent: Tuesday, October 20, 2020 8:43 PM
To: yocto@lists.yoctoproject.org
Cc: Saini, Naveen Kumar <naveen.kumar.saini@intel.com>
Subject: [meta-zephyr][PATCH] zephyr: use TCLIBC=newlib directly

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@arm.com>
---
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


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

Yocto
 


On 10/20/20 8:06 PM, NIKHIL PATIL wrote:
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

I can confirm that Ive also seen this trying to build in the Yocto build appliance I downloaded yesterday....



>
> 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: dnf error coming while compiling core-image-sato image.

NIKHIL PATIL
 

Hi team,
    I am not able compile a core-image-minimal also. same issue facing here.
   PFA (local.conf) .   

On Tue, Oct 20, 2020 at 7:50 PM Randy MacLeod <randy.macleod@...> wrote:
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: QA notification for completed autobuilder build (yocto-3.2.rc1)

Sangeeta Jain
 

Hi all,

Intel and WR YP QA is planning for QA execution for YP build yocto-3.2.rc1
We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. Coffee Lake
3. NUC 7
4. NUC 6
5. Edgerouter
6. Beaglebone

ETA for completion is next Monday, October 26.

Thanks,
Sangeeta

-----Original Message-----
From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On Behalf
Of Pokybuild User
Sent: Wednesday, 21 October, 2020 12:36 AM
To: yocto@lists.yoctoproject.org
Cc: otavio@ossystems.com.br; yi.zhao@windriver.com; Sangal, Apoorv
<apoorv.sangal@intel.com>; Yeoh, Ee Peng <ee.peng.yeoh@intel.com>; Chan,
Aaron Chun Yew <aaron.chun.yew.chan@intel.com>;
richard.purdie@linuxfoundation.org; akuster808@gmail.com;
sjolley.yp.pm@gmail.com; Jain, Sangeeta <sangeeta.jain@intel.com>
Subject: [yocto] QA notification for completed autobuilder build (yocto-3.2.rc1)


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@linuxfoundation.org



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@arm.com>
---
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@lists.yoctoproject.org
+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@lists.yoctoproject.org
+$ 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@linuxfoundation.org


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

Anibal Limon
 

Signed-off-by: Aníbal Limón <anibal.limon@linaro.org>
---
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@windriver.com <mailto:randy.macleod@windriver.com>> 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@lists.yoctoproject.org> 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@arm.com>
---
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@arm.com>
---
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@lists.yoctoproject.o=
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@lists.yoctoproject.org
+$ 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

921 - 940 of 52041