Date   

run.do_image_zipabox2_sdimg.27223: parted: not found

Yocto
 

having a really funky issue everything builds fine under pyro updated it all to dunfell, and now im hitting this failure below, i also pasted the log and the offending recipe on pastebin logfile: https://pastebin.com/38TzNa5h bb recipe: https://pastebin.com/jhfTBv58 Logfile of failure stored in: /home/dingo/TEST3/Zipato/zipato-yocto-public/build/tmp/work/zipabox2-poky-linux-gnueabi/zipabox2-image-blank/1.0-r0/temp/log.do_image_zipabox2_sdimg.27223 Log data follows: | DEBUG: Executing python function set_image_size | DEBUG: 1032444.400000 = 794188 * 1.300000 | DEBUG: 1032444.400000 = max(1032444.400000, 8192)[1032444.400000] + 0 | DEBUG: 1032445.000000 = int(1032444.400000) | DEBUG: 1032445 = aligned(1032445) | DEBUG: returning 1032445 | DEBUG: Python function set_image_size finished | DEBUG: Executing shell function do_image_zipabox2_sdimg | 0+0 records in | 0+0 records out | 0 bytes copied, 8.9773e-05 s, 0.0 kB/s | /home/dingo/TEST3/Zipato/zipato-yocto-public/build/tmp/work/zipabox2-poky-linux-gnueabi/zipabox2-image-blank/1.0-r0/temp/run.do_image_zipabox2_sdimg.27223: 124: /home/dingo/TEST3/Zipato/zipato-yocto-public/build/tmp/work/zipabox2-poky-linux-gnueabi/zipabox2-image-blank/1.0-r0/temp/run.do_image_zipabox2_sdimg.27223: parted: not found | WARNING: exit code 127 from a shell command. | ERROR: Execution of '/home/dingo/TEST3/Zipato/zipato-yocto-public/build/tmp/work/zipabox2-poky-linux-gnueabi/zipabox2-image-blank/1.0-r0/temp/run.do_image_zipabox2_sdimg.27223' failed with exit code 127: | 0+0 records in | 0+0 records out | 0 bytes copied, 8.9773e-05 s, 0.0 kB/s | /home/dingo/TEST3/Zipato/zipato-yocto-public/build/tmp/work/zipabox2-poky-linux-gnueabi/zipabox2-image-blank/1.0-r0/temp/run.do_image_zipabox2_sdimg.27223: 124: /home/dingo/TEST3/Zipato/zipato-yocto-public/build/tmp/work/zipabox2-poky-linux-gnueabi/zipabox2-image-blank/1.0-r0/temp/run.do_image_zipabox2_sdimg.27223: parted: not found | WARNING: exit code 127 from a shell command. | ERROR: Task (/home/dingo/TEST3/Zipato/zipato-yocto-public/meta-zipato-public/images/zipabox2-image/zipabox2-image-blank_1.0.bb:do_image_zipabox2_sdimg) failed with exit code '1' NOTE: Tasks Summary: Attempted 4542 tasks of which 4540 didn't need to be rerun and 2 failed. Summary: 2 tasks failed: /home/dingo/TEST3/Zipato/zipato-yocto-public/meta-zipato-public/images/zipabox2-image/zipabox2-image-blank_1.0.bb:do_image_zipabox2_mender /home/dingo/TEST3/Zipato/zipato-yocto-public/meta-zipato-public/images/zipabox2-image/zipabox2-image-blank_1.0.bb:do_image_zipabox2_sdimg -- 
Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com


Re: Zuul - Project Gating System with Yocto Project

Joshua Watt
 


On 7/1/21 9:48 AM, Tomasz Dziendzielski wrote:
Hello,
is anyone here using Zuul along with Yocto Project? We are thinking about integrating Zuul to our project that already uses Yocto, but we are not too familiar with Zuul and we want it to conform to good open source practices, without losing any advantages of both projects and we want to avoid creating some hacky monster.
Could you share some suggestions on how it can be combined together and what is the best approach/structure to do this? Please also share if you have some "what I wish I'd known" about Zuul integration to Yocto. Any hints are appreciated.


I haven't, but it's on my radar to look at as it seems like it could be pretty useful. If you look into it, please share your findings!



Best regards,
Tomasz Dziendzielski




Zuul - Project Gating System with Yocto Project

Tomasz Dziendzielski
 

Hello,
is anyone here using Zuul along with Yocto Project? We are thinking about integrating Zuul to our project that already uses Yocto, but we are not too familiar with Zuul and we want it to conform to good open source practices, without losing any advantages of both projects and we want to avoid creating some hacky monster.
Could you share some suggestions on how it can be combined together and what is the best approach/structure to do this? Please also share if you have some "what I wish I'd known" about Zuul integration to Yocto. Any hints are appreciated.

Best regards,
Tomasz Dziendzielski


Yocto Autobuilder: Latency Monitor and AB-INT - Meeting notes: July 1, 2021

Randy MacLeod
 

YP AB Intermittent failures meeting
===================================
July 1, 2021, 9 AM ET
https://windriver.zoom.us/j/3696693975

Attendees: Alex, Richard, Saul, Randy


Summary:
========

The autobuilder RCU hang is fixed, build greener.
ptest failures (some glibc-2.34) are the top problem now.

Add Michael Halstead, see questions below in section 4.

If anyone wants to help, we could use more eyes on the logs,
particularly the summary logs and understanding iostat #
when the dd test times out.


Plans for the week:

===================


Richard: glibc upgrade, etc.

Alex: ?

Sakib: pub/non-release link upgrade, script clean-up.

Trevor: make job server test. Try it on YP AB!!! What type of build?

Tony: nothing this week for YP.

Saul: nothing this week for YP.

Randy: vacation!


Meeting Notes:
==============

1. The qemu RCU hang has been fixed to not deadlock anymore!

It still hangs at times but this dramatically reduces the
AB failures.


2. Lots of ptest failures with
- tcl
- valgrind
especially with the upreved glibc-2.34.

3. YP AB INT # bugs reduced: down to ~ 47
Richard went through the list and closed ~ 10 bugs.
- RCU, LTP bugs closed.
- qemu ping bug remains
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14029

4. bitbake server timeout.

"Timeout while waiting for a reply from the bitbake server (60s)"

Randy mentioned that the bitbake server timeouts seen in the
Wind River build cluster have gone away after upgrading to
a newer version of docker.

Old: Docker Version: Docker version 18.09.4, build d14af54266
New: Docker Version: Docker version 20.10.7, build f0df350


Clearly the YP ABs aren't running in docker but what
about firmware and kernel tunings.

Michael,

Is the BIOS/firmware kept up to date on most nodes?

It seems that we are running stock kernels which makes sense but
given that we don't have concerns about privacy since system access
is controlled and the nodes are being used to test open
source software, we might consider optimizing for performance
rather than security.

Alex pointed at: https://make-linux-fast-again.com/
Which just lists a set of kernel boot options:
noibrs noibpb nopti nospectre_v2 nospectre_v1 \
l1tf=off nospec_store_bypass_disable no_stf_barrier \
mds=off tsx=on tsx_async_abort=off mitigations=off

Can we enable some or all of these on a node to see what the
performance difference is?


5. io stalls

Richard said that it would make sense to write an ftrace utility
/ script to monitor io latency and we could install it with sudo
Ch^W mentioned ftrace on IRC.
Sakib and Randy will work on that but not for a week or two.

6. Switch the pub/non-release links from full log to summary.
The host data links on:
https://autobuilder.yocto.io/pub/non-release/
should include links to the summary data. I think we have room to
include both links like this:
0 1 2 3 (Full: 0 1 2 3 )

7. Qemu machine protocol debugging commands

Saul's patch is in.


8. System load: make, ninja jobs

Trevor has been busy with other work but has been playing with
kea and make -l: load average calculation
https://github.com/mirror/make/blob/master/src/job.c#L1947


We're confirmed that this actually works on a build server and
for all versions of make in the cluster.

Randy may write to Paul Smith about the general problem we
are having.


9. iostat

The iostat output is in some of the AB logs:
https://autobuilder.yocto.io/pub/non-release/
for example:

https://autobuilder.yocto.io/pub/non-release/20210623-17/testresults/meta-oe/2021-06-23--21-51/host_stats_0_top.txt

search for "start: iostat"
it looks like the io sub-systems are 100% utilized but
we need more time, data and the summary script to be able to easily
make a general statement about AB INT issues and IO load and
to be able to identify what is typically generating the IO load.




../Randy


Re: [meta-cgl][PATCH] layer.conf: add hardknott to LAYERSERIES_COMPAT

Jeremy Puhlman
 

Merged. Thanks.

On 6/30/2021 10:10 PM, Chen Qi wrote:
Signed-off-by: Chen Qi <Qi.Chen@...>
---
 meta-cgl-common/conf/layer.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-cgl-common/conf/layer.conf b/meta-cgl-common/conf/layer.conf
index 8100e23..56ddbb9 100644
--- a/meta-cgl-common/conf/layer.conf
+++ b/meta-cgl-common/conf/layer.conf
@@ -11,6 +11,6 @@ BBFILE_PRIORITY_cgl-common = "7"
 
 LAYERDEPENDS_cgl-common = "core openembedded-layer networking-layer perl-layer filesystems-layer security selinux"
 
-LAYERSERIES_COMPAT_cgl-common = "warrior zeus dunfell gatesgarth"
+LAYERSERIES_COMPAT_cgl-common = "warrior zeus dunfell gatesgarth hardknott"
 
 require conf/distro/include/cgl_common_security_flags.inc





[meta-cgl][PATCH] layer.conf: add hardknott to LAYERSERIES_COMPAT

Chen Qi
 

Signed-off-by: Chen Qi <Qi.Chen@...>
---
meta-cgl-common/conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-cgl-common/conf/layer.conf b/meta-cgl-common/conf/layer.conf
index 8100e23..56ddbb9 100644
--- a/meta-cgl-common/conf/layer.conf
+++ b/meta-cgl-common/conf/layer.conf
@@ -11,6 +11,6 @@ BBFILE_PRIORITY_cgl-common = "7"

LAYERDEPENDS_cgl-common = "core openembedded-layer networking-layer perl-layer filesystems-layer security selinux"

-LAYERSERIES_COMPAT_cgl-common = "warrior zeus dunfell gatesgarth"
+LAYERSERIES_COMPAT_cgl-common = "warrior zeus dunfell gatesgarth hardknott"

require conf/distro/include/cgl_common_security_flags.inc
--
2.17.1


[ANNOUNCEMENT] Yocto Project 3.1.9 (dunfell-23.0.9) is Released

Vineela
 

Hello,

 

We are pleased to announce the Yocto Project 3.1.9 (dunfell-23.0.9) Release is now available for download.

 

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/poky-dunfell-23.0.9.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.9/poky-dunfell-23.0.9.tar.bz2

 

A gpg signed version of these release notes is available at:

 

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/RELEASENOTES

 

Full Test Report:

 

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/testreport.txt

 

Thank you for everyone's contributions to this release.

 

Vineela Tummalapalli

Yocto Project Build and Release

vineela.tummalapalli@...

 

- --------------------------

yocto-3.1.9 Release Notes

- --------------------------

 

- --------------------------

Repositories/Downloads

- --------------------------

 

Repository Name: poky

Repository Location: https://git.yoctoproject.org/git/poky

Branch: dunfell

Tag: yocto-3.1.9

Git Revision: 43060f59ba60a0257864f1f7b25b51fac3f2d2cf

Release Artefact: poky-dunfell-23.0.9

sha: d2a7acbaca384408594b72f25883f10b454215af97e31914e8a11035a0334424

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/poky-dunfell-23.0.9.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.9/poky-dunfell-23.0.9.tar.bz2

 

Repository Name: openembedded-core

Repository Location: https://git.openembedded.org/openembedded-core

Branch: dunfell

Tag: 2020-04.9-dunfell

Git Revision: ac8181d9b9ad8360f7dba03aba8b00f008c6ebb4

Release Artefact: oecore-dunfell-23.0.9

sha: d4fc5e5333bc6b2dee464d1845554920e3d504ab16a47e6d335d5c8a185e0dcd

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/oecore-dunfell-23.0.9.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.9/oecore-dunfell-23.0.9.tar.bz2

 

Repository Name: meta-mingw

Repository Location: https://git.yoctoproject.org/git/meta-mingw

Branch: dunfell

Tag: yocto-3.1.9

Git Revision: 524de686205b5d6736661d4532f5f98fee8589b7

Release Artefact: meta-mingw-dunfell-23.0.9

sha: e5f8e6777003d329fe7ff9e69c9e9f46edf5a272198a194cbc79b866c7b9dab6

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/meta-mingw-dunfell-23.0.9.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.9/meta-mingw-dunfell-23.0.9.tar.bz2

 

Repository Name: meta-gplv2

Repository Location: https://git.yoctoproject.org/git/meta-gplv2

Branch: dunfell

Tag: yocto-3.1.9

Git Revision: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac

Release Artefact: meta-gplv2-dunfell-23.0.9

sha: 39bffee0bc5a93e224073036e6a544d83c40f5bccc4c8faeb3995cef323969e1

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/meta-gplv2-dunfell-23.0.9.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.9/meta-gplv2-dunfell-23.0.9.tar.bz2

 

Repository Name: bitbake

Repository Location: https://git.openembedded.org/bitbake

Branch: 1.46

Tag: 2020-04.9-dunfell

Git Revision: 0e0af15b84e07e6763300dcd092b980086b9b9c4

Release Artefact: bitbake-dunfell-23.0.9

sha: 9a3da4317d9e43ef9b0e66ed0d8070d373fc41fa34648e2a6b04c591d12b97d0

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/bitbake-dunfell-23.0.9.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.9/bitbake-dunfell-23.0.9.tar.bz2

 

Repository Name: yocto-docs

Repository Location: https://git.yoctoproject.org/git/yocto-docs

Branch: dunfell

Tag: yocto-3.1.9

Git Revision:0fadb292429b4147408798ed4c806ba6d9dd81b8

 

- -------------

Contributors

- -------------

akash hadke

Andrea Adami

Bruce Ashfield

Changqing Li

Daniel McGregor

Guillaume Champagne

Jain Sangeeta

Kai Kang

Klaus Heinrich Kiwi

Lee Chee Yang

Michael Halstead

Ming Liu

Ovidiu Panait

Richard Purdie

Ross Burton

Sana Kazi

Stephen Jolley

Steve Sakoman

Tony Tascioglu

Vineela Tummalapalli

Volker Vogelhuber

Yi Zhao

 

- ---------------

Known Issues

- ---------------

N/A

 

 

- ---------------

Security Fixes

- ---------------

Revert "python3: fix CVE-2021-23336"

python3: fix CVE-2021-23336

gstreamer-plugins-good: fix CVE-2021-3497 CVE-2021-3498

gnutls: fix CVE-2021-20231 CVE-2021-20232

libxml: fix CVE-2021-3517 CVE-2021-3537

grub: Exclude CVE-2019-14865 from cve-check

cve-extra-exclusions.inc: add exclusion list for intractable CVE's

expat: set CVE_PRODUCT

openssh: Add fixes for CVEs reported for openssh

tiff: Add fix for CVE-2020-35521 and CVE-2020-35522

cups: whitelist CVE-2021-25317

 

 

- ---------------

Fixes

- ---------------

bitbake: cooker: Avoid parser deadlocks

bitbake: cooker: Ensure parser is cleaned up

bitbake: cooker: Explictly shut down the sync thread

bitbake: cooker: Ensure parse_quit thread is closed down

kernel.bbclass: fix do_sizecheck() comparison

valgrind: fix a typo

ruby: 2.7.1 -> 2.7.3

bind: 9.11.22 -> 9.11.32

poky.conf: Bump version for 3.1.9 release

poky.conf: Add openSUSE Leap 15.2 as a supported distro

documentation: prepare for 3.1.9 release

ref-system-requirements.rst: Add openSUSE Leap 15.2 to list of supported distros

variables: Add documentation for KERNEL_DTC_FLAGS

kernel-devicetree: Introduce KERNEL_DTC_FLAGS to pass dtc flags

kernel-fitimage: Don't use unit addresses on FIT

linux-yocto/5.4: update to v5.4.123

linux-yocto/5.4: update to v5.4.120

Revert "busybox: make busybox's syslog.cfg depend on VIRTUAL-RUNTIME_base-utils-syslog"

linux-firmware: upgrade 20210315 -> 20210511

pkgconfig: update SRC_URI

oeqa/runtime/rpm: Drop log message counting test component

image-live.bbclass: order do_bootimg after do_rootfs

package_rpm: pass XZ_THREADS to rpm

unfs3: correct configure option

initramfs-framework:rootfs: fix wrong indentions

kernel-fitimage.bbclass: fix a wrong conditional check

lib/oe/gpg_sign.py: Fix gpg verification

sstate: Ignore sstate signing key

glibc: Add 8GB VM usage cap for usermode test suite

libxml2: Add bash dependency for ptests.

libxml2: Reformat runtest.patch

linux-yocto/5.4: update to v5.4.119

linux-yocto/5.4: update to v5.4.118

linux-yocto/5.4: update to v5.4.117

kernel-yocto: provide debug / summary information for metadata

busybox: make busybox's syslog.cfg depend on VIRTUAL-RUNTIME_base-utils-syslog

cve-extra-exclusions.inc: Clean up merged CPE updates

cve-extra-exclusions: Fix typos


Re: Would COMPATIBLE_IMAGE make sense?

Jonas Vautherin
 

Thanks a lot for the answers, that's really helpful!

Seems like I should have a closer look at the distros.
I'll need some time to test it, I'll update here when that is done!

On Tue, Jun 29, 2021 at 1:52 PM Bruce Ashfield <bruce.ashfield@...> wrote:
On Tue, Jun 29, 2021 at 2:41 AM Josef Holzmayr
<jester@...> wrote:
>
> Howdy!
>
> Am 29.06.2021 um 01:28 schrieb Jonas Vautherin:
> > I was thinking about my issue described here [1], and discovered the
> > variables called COMPATIBLE_MACHINE and COMPATIBLE_HOST, which "you can
> > use to stop recipes from being built for machines (/hosts) with which
> > the recipes are not compatible". And so I wondered if it would make
> > sense to add COMPATIBLE_IMAGE, for a similar purpose.
> >
> > Let me explain my issue: I define different images in different layers
> > (say `first-project-image` and `second-project-image`), and in each of
> > those layers I create `.bbappends` to configure some packages. Typically
> > `hostapd` is used by both images, but with a different config file.
> >
> > The thing is that when I run `bitbake first-project-image`, because
> > `second-project-image` is part of my bblayers.conf, then the
> > hostapd_%.bbappend from `second-project-image` is used and may have an
> > impact on `first-project-image`, which I don't want. I really want this
> > bbappend to only affect the image `second-project-image`.
> >
> > One way I can see to deal with that is to realize that
> > `first-project-image` and `second-project-image` are two different
> > projects, and build them from two different BUILDDIRs. The thing I don't
> > like here is that all the packages are therefore downloaded and built
> > twice, which seems like a loss of time and space.
> >
> > That's where I thought about COMPATIBLE_IMAGE. In the hostapd_%.bbappend
> > of `first-project-image`, I would set "COMPATIBLE_IMAGE =
> > 'first-project-image'", and similarly for "COMPATIBLE_IMAGE =
> > 'second-project-image'". So that I could still share a BUILDDIR between
> > different projects.
>
> Yocto chant #1 applies: "Recipe data is local, configuration data is
> global." Means: the recipe does not see at all which image it is being
> built for. So it also can't react to it - you can't check a variable
> against something you do not even see.
>
> > How bad of an idea is that?
>
> It just doesn't work. If that counts as "bad" is left for you to decide :)
>
> What you actually might use is using different DISTROs for the images,
> because that actually what they mean to do: you change the ABI/API of
> the image. And you can also define a base DISTRO and COMPATIBLE_DISTRO
> derivatives, so its all there already. It just cannot be triggered from
> the image, because, well.. see first pragraph of the answer.

I was also going to suggest distros.

And also, if the concern really is about builds reusing downloads,
etc, then by all means configure those different distro builds to
share download and sstate directories.

Bruce

>
> Greetz
>
> > Thanks in advance,
> > Jonas
> >
> > [1]: https://stackoverflow.com/questions/68167244/image-specific-layers
> > <https://stackoverflow.com/questions/68167244/image-specific-layers>
> >
> >
> >
> >
>
>
>


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




Re: [meta-rockchip][PATCH 3/3] wic/wks cleanup

Trevor Woerner
 

On Mon 2021-06-28 @ 11:15:41 AM, Trevor Woerner wrote:
By exporting a couple more variables the wks file for every rockchip device
can be built from one template instead of having separate wks files for each
board and platform.

The following BSP variables were checked before and after this change to make
sure they remained valid/sensible:
- WKS_FILE
- UBOOT_SUFFIX
- SPL_BINARY
- IMAGE_FSTYPES

Built-tested for every MACHINE in this BSP.

Run-tested on the following devices to ensure they continue to boot correctly
to a cmdline (core-image-base):
- tinker-board
- rock-pi-e
- rock-pi-4b
- rock64
- nanopi-m4-2gb

Signed-off-by: Trevor Woerner <twoerner@...>
---
conf/machine/firefly-rk3288.conf | 2 --
conf/machine/include/nanopi-m4.inc | 1 -
conf/machine/include/rk3288.inc | 3 +--
conf/machine/include/rk3328.inc | 1 -
conf/machine/include/rk3399.inc | 2 --
conf/machine/include/rock-pi-4.inc | 1 -
conf/machine/include/rockchip-wic.inc | 5 +++++
conf/machine/include/tinker.inc | 2 --
conf/machine/rock-pi-e.conf | 2 --
conf/machine/rock64.conf | 2 --
conf/machine/vyasa-rk3288.conf | 1 -
wic/firefly-rk3288.wks | 7 -------
wic/rk3288-boot.wks | 24 ------------------------
wic/rk3399-boot.wks | 24 ------------------------
wic/rock-pi-4.wks | 7 -------
wic/rock-pi-e.wks | 4 ----
wic/{rk3328-boot.wks => rockchip.wks} | 9 ++++++---
wic/tinker-board.wks | 8 --------
wic/vyasa-rk3288.wks | 8 --------
19 files changed, 12 insertions(+), 101 deletions(-)
delete mode 100644 wic/firefly-rk3288.wks
delete mode 100644 wic/rk3288-boot.wks
delete mode 100644 wic/rk3399-boot.wks
delete mode 100644 wic/rock-pi-4.wks
delete mode 100644 wic/rock-pi-e.wks
rename wic/{rk3328-boot.wks => rockchip.wks} (64%)
delete mode 100644 wic/tinker-board.wks
delete mode 100644 wic/vyasa-rk3288.wks

diff --git a/conf/machine/firefly-rk3288.conf b/conf/machine/firefly-rk3288.conf
index 138e840..3270bb9 100644
Applied to meta-rockchip master.


Re: [meta-rockchip][PATCH 2/3] IMAGE_FSTYPES: remove ext4

Trevor Woerner
 

On Mon 2021-06-28 @ 11:15:40 AM, Trevor Woerner wrote:
The ext4 IMAGE_FSTYPES does not need to be mentioned explicitly. It will be
automatically generated in cases where it is needed.

Signed-off-by: Trevor Woerner <twoerner@...>
---
conf/machine/include/rockchip-defaults.inc | 1 -
1 file changed, 1 deletion(-)

diff --git a/conf/machine/include/rockchip-defaults.inc b/conf/machine/include/rockchip-defaults.inc
index b41c523..0666119 100644
Applied to meta-rockchip master.


Re: [meta-rockchip][PATCH 1/3] conf/machine/include/nanopi-m4.inc: add full include path

Trevor Woerner
 

On Mon 2021-06-28 @ 11:15:39 AM, Trevor Woerner wrote:
Specify the full include path to the rk3399.inc file.

Signed-off-by: Trevor Woerner <twoerner@...>
---
conf/machine/include/nanopi-m4.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/machine/include/nanopi-m4.inc b/conf/machine/include/nanopi-m4.inc
index 7ca91db..b5251a1 100644
Applied to meta-rockchip master.


Re: Python2 in Gatesgarth

Marek Belisko
 

Hi Aashik,

On Wed, Jun 30, 2021 at 4:25 PM Aashik Aswin <thisisaash9698@...> wrote:

Hello Developers,

We are migrating our platforms from Zeus to Gatesgarth, We could see that the native Python2 bb file and core modules have been removed.

As much of our platform code is in Python2, I was wondering if there is some way we can re-enable python2 support in our yocto environment to compile/run python2 scripts ?
You can use meta-python2 [0] layer

Thanks in Advance,

Thanks & Regards
Aashik


[0] - https://git.openembedded.org/meta-python2

marek


Python2 in Gatesgarth

Aashik Aswin
 

Hello Developers,

We are migrating our platforms from Zeus to Gatesgarth, We could see that the native Python2 bb file and core modules have been removed.

 As much of our platform code is in Python2, I was wondering if there is some way we can re-enable python2 support in our yocto environment to compile/run python2 scripts ?

Thanks in Advance,

Thanks & Regards
Aashik


#yocto #zeus #yocto #zeus

Monsees, Steven C (US)
 

 

I am running with zeus 3.0.4 and appear to have an issue with the mount command supporting NFS… ?

 

Can someone explain the following and how I can get “mount” to support NFS ?

 

Trying to mount the UDM from the AIO

mount.nfs: Operation not permitted

Failed to mount the UDM from the AIO!

Trying tNFS: bad mount option value specified: minorversion=1

 

Thanks,

Steve


Question regarding custom device tree update

Sohil Shah <sohils@...>
 

Hello,

I am kinda a noob at this so please bear with me.

I am using the sama5d27-wlsom1-ek board for my demo and I am trying to make changes to the device tree.

So far I have compiled core-image-minimal and find my dtb files are generated in
/tmp/work/sama5d27_wlsom1_ek_sd-poky-linux-gnueabi/linux-at91/5.4+gitAUTOINC+3dba8c9991-r0/build/arch/arm/boot/dts
folder.

Also I find many different dts files in
build/tmp/work-shared/sama5d27-wlsom1-ek-sd/kernel-source/arch/arm/boot/dts

But where does my machine get device tree files if they are generated inside the build folder and if so where do I place my custom files so that they get called during bitbake.

I want to build the image using my custom dts file where I enable certain peripherals and disable the ones not required. (A test to update dtb's in future).

I tried different methods found here

But, I seem to run into some errors when I try to build the image.

Please help and let me know if I missed any required information from my side.

Thank you and Regards,
Sohil


[poky][PATCH] devtool: deploy-target: Fix preserving attributes when using --strip

Florian Amstutz
 

Commit a2db4fa127a3347fc6df31f895fb0b552669119e added ${WORKDIR}/deploy-* to
PSEUDO_IGNORE_PATHS. This breaks the --strip mode since ${D} is copied to
deploy-target-stripped. Use the directory devtool-deploy-target-stripped
instead.

[YOCTO #14451]

Signed-off-by: Florian Amstutz <florian.amstutz@...>
---
 scripts/lib/devtool/deploy.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
diff --git a/scripts/lib/devtool/deploy.py b/scripts/lib/devtool/deploy.py
index e5af2c95ae..833322571f 100644
--- a/scripts/lib/devtool/deploy.py
+++ b/scripts/lib/devtool/deploy.py
@@ -168,7 +168,7 @@ def deploy(args, config, basepath, workspace):
         if args.strip and not args.dry_run:
             # Fakeroot copy to new destination
             srcdir = recipe_outdir
-            recipe_outdir = os.path.join(rd.getVar('WORKDIR'), 'deploy-target-stripped')
+            recipe_outdir = os.path.join(rd.getVar('WORKDIR'), 'devtool-deploy-target-stripped')
             if os.path.isdir(recipe_outdir):
                 bb.utils.remove(recipe_outdir, True)
             exec_fakeroot(rd, "cp -af %s %s" % (os.path.join(srcdir, '.'), recipe_outdir), shell=True)
-- 
2.17.1
 


Re: Launching script at the very end of the image process

Richard Purdie
 

On Wed, 2021-06-30 at 10:41 +0000, Cardaillac, Yann wrote:
Hi Richard,

Many thanks for the fast answer.

I’m switching from buildroot to yocto and trying to figure out how to
do the equivalent of a POST_BUILD_SCRIPT.

Indeed I want to format the images built in a specific format for latter use and CI needs.
In OE, the equivalent for that is probably the image types code.
See http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/image_types.bbclass

You can define your own custom image types to extend the system. Some of our defaults are quite simple (tar), some are quite complex (wic has its own bbclass).
I said image, but it was probably not the best word, I just want to make a tarball 
of the generated image + adding some file in it.

Here's the complete file with the job :

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

SRC_URI += "file://nallino-custom-params.txt"
SRC_URI += "file://configuration_instruction_to_do_on_GUF.txt"

do_release_ycn() {

    rm -rf ${DEPLOY_DIR_IMAGE}/ycn_release
    mkdir -p ${DEPLOY_DIR_IMAGE}/ycn_release/overlays
    cp ${DEPLOY_DIR_IMAGE}/fng-install.sh ${DEPLOY_DIR_IMAGE}/ycn_release
    cp ${DEPLOY_DIR_IMAGE}/ycn-image-imx6ullguf.tar.gz ${DEPLOY_DIR_IMAGE}/ycn_release/guf-image-imx6ullguf.tar.gz
    cp ${DEPLOY_DIR_IMAGE}/*.dtbo ${DEPLOY_DIR_IMAGE}/ycn_release/overlays
    cp ${WORKDIR}/nallino-custom-params.txt ${DEPLOY_DIR_IMAGE}/ycn_release/
    cp ${WORKDIR}/configuration_instruction_to_do_on_GUF.txt ${DEPLOY_DIR_IMAGE}/ycn_release/
    tar -czf ${DEPLOY_DIR_IMAGE}/ycn_release.tar.gz ${DEPLOY_DIR_IMAGE}/ycn_release

}
addtask release_ycn after do_image_complete after do_deploy_kernelmodules
You're used to poking around things in buildroot, OE doesn't quite like you
doing that so much :)

You shouldn't really be poking around DEPLOY_DIR without letting the build
system know what you're doing. Intermediate files like the intermediate directory
you're using to create the tarball above should really be in WORKDIR.
That is itself won't break, it just not good practise. Ideally you'd write
a separate recipe to do this final piece with a do_deploy task, using the
deploy bbclass which would them take care of removing obsolete versions
when you rebuild and so on.

I’ve also tried to use IMAGE_POSTPROCESS_COMMAND without much success
since it wasn’t running at the proper moment.
When is "the right moment"? :)
The right moment, is at the very end of bitbake, indeed I want the job 
to be the overall last job!
You're not really helping us help you find a solution since you've not described
what you'd expect to be happening that isn't happening. How is what you have
failing?

I'm going to take a leap and guess that some of the files you expect there
aren't? Maybe the dtbo files from some other do_deploy tasks? If that is true
you're missing dependencies for your task. You can do things like:

do_release_ycn[depends] += "virtual/kernel:do_deploy"

I'd caution against "last" as it is a fine concept until two things want to 
be "last". It is usually better to describe the dependencies properly.

Cheers,

Richard


Re: Launching script at the very end of the image process

Cardaillac, Yann
 

Hi Richard,

Many thanks for the fast answer.

I’m switching from buildroot to yocto and trying to figure out how to
do the equivalent of a POST_BUILD_SCRIPT.

Indeed I want to format the images built in a specific format for latter use and CI needs.
In OE, the equivalent for that is probably the image types code.
See http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/image_types.bbclass

You can define your own custom image types to extend the system. Some of our defaults are quite simple (tar), some are quite complex (wic has its own bbclass).
I said image, but it was probably not the best word, I just want to make a tarball of the generated image + adding some file in it.

Here's the complete file with the job :

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

SRC_URI += "file://nallino-custom-params.txt"
SRC_URI += "file://configuration_instruction_to_do_on_GUF.txt"

do_release_ycn() {

rm -rf ${DEPLOY_DIR_IMAGE}/ycn_release
mkdir -p ${DEPLOY_DIR_IMAGE}/ycn_release/overlays
cp ${DEPLOY_DIR_IMAGE}/fng-install.sh ${DEPLOY_DIR_IMAGE}/ycn_release
cp ${DEPLOY_DIR_IMAGE}/ycn-image-imx6ullguf.tar.gz ${DEPLOY_DIR_IMAGE}/ycn_release/guf-image-imx6ullguf.tar.gz
cp ${DEPLOY_DIR_IMAGE}/*.dtbo ${DEPLOY_DIR_IMAGE}/ycn_release/overlays
cp ${WORKDIR}/nallino-custom-params.txt ${DEPLOY_DIR_IMAGE}/ycn_release/
cp ${WORKDIR}/configuration_instruction_to_do_on_GUF.txt ${DEPLOY_DIR_IMAGE}/ycn_release/
tar -czf ${DEPLOY_DIR_IMAGE}/ycn_release.tar.gz ${DEPLOY_DIR_IMAGE}/ycn_release

}
addtask release_ycn after do_image_complete after do_deploy_kernelmodules


I’ve also tried to use IMAGE_POSTPROCESS_COMMAND without much success
since it wasn’t running at the proper moment.
When is "the right moment"? :)
The right moment, is at the very end of bitbake, indeed I want the job to be the overall last job!

Thanks again,

Yann


Re: Launching script at the very end of the image process

Richard Purdie
 

On Wed, 2021-06-30 at 09:33 +0000, Cardaillac, Yann wrote:
I’m switching from buildroot to yocto and trying to figure out how to do the equivalent of a
POST_BUILD_SCRIPT.
 
Indeed I want to format the images built in a specific format for latter use and CI needs.
In OE, the equivalent for that is probably the image types code.
See http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/image_types.bbclass

You can define your own custom image types to extend the system. Some of our defaults
are quite simple (tar), some are quite complex (wic has its own bbclass).

I’ve also tried to use IMAGE_POSTPROCESS_COMMAND without much success since it 
wasn’t running at the proper moment.
When is "the right moment"? :)

Cheers,

Richard


man package issue

sateesh m
 

Hi Guys,

             I am building core-image-sato image. i am facing issue rootfs creation. can anybody know give suggition how we can solve this issue.

ERROR: core-image-sato-1.0-r0 do_rootfs: Postinstall scriptlets of ['man-pages'] have failed. If the intention is to defer them to first boot,
then please place them into pkg_postinst_ontarget_${PN} ().
Deferring to first boot via 'exit 1' is no longer supported.
 

--
Thanks & Regards,
Sateesh

3401 - 3420 of 57398