Date   

Re: [meta-raspberrypi][PATCH] linux-firmware-rpidistro: add branch in SRC_URI

Devendra Tewari
 

On 18 Nov 2021, at 19:17, Devendra Tewari <devendra.tewari@...> wrote:

Thanks.

Em 18 de nov. de 2021, à(s) 18:17, Martin Jansa <martin.jansa@...> escreveu:


On Thu, Nov 18, 2021 at 9:01 PM Devendra Tewari <devendra.tewari@...> wrote:
Branch master has been renamed to buster. Also setting protocol to
https as GitHub is migrating away from unencrypted git protocol

Signed-off-by: Devendra Tewari <devendra.tewari@...>
---
 .../linux-firmware-rpidistro/linux-firmware-rpidistro_git.bb    | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-kernel/linux-firmware-rpidistro/linux-firmware-rpidistro_git.bb b/recipes-kernel/linux-firmware-rpidistro/linux-firmware-rpidistro_git.bb
index a091585..874e444 100644
--- a/recipes-kernel/linux-firmware-rpidistro/linux-firmware-rpidistro_git.bb
+++ b/recipes-kernel/linux-firmware-rpidistro/linux-firmware-rpidistro_git.bb
@@ -34,7 +34,7 @@ LIC_FILES_CHKSUM = "\
 NO_GENERIC_LICENSE[Firmware-broadcom_bcm43xx-rpidistro] = "LICENCE.broadcom_bcm43xx"
 NO_GENERIC_LICENSE[WHENCE] = "WHENCE"

-SRC_URI = "git://github.com/RPi-Distro/firmware-nonfree"
+SRC_URI = "git://github.com/RPi-Distro/firmware-nonfree;protocol=https;branch=buster"

 SRCREV = "83938f78ca2d5a0ffe0c223bb96d72ccc7b71ca5"
 PV = "20190114-1+rpt11"
--
2.33.1






Re: Private: Re: [yocto] #yocto Remove hexdump from image #yocto

Josef Holzmayr
 

(re-adding list)

Am 19.11.2021 um 10:11 schrieb lucapirozzi via lists.yoctoproject.org:
Hi Joseph,

thank you for replying.

Shall I use oe-pkgdata-util find-patch this way?

oe-pkgdata-util  find-path /usr/bin/hexdump

Because it gives me an error
ERROR: Unable to find any package producing path /usr/bin/hexdump
You have to use the path you found hexdump at. Check in your running target by using "which", or inspect the image contents.


Greetz


So I think I am doing something wrong. Maybe the folder I am launching the script from?


Re: #yocto Remove hexdump from image #yocto

lucapirozzi@...
 

Hi Joseph,

thank you for replying.

Shall I use the oe-pkgdata-util find-path this way?

oe-pkgdata-util  find-path /usr/bin/hexdump

Because I'm encountering an error
ERROR: Unable to find any package producing path /usr/bin/hexdump

So I think I am doing something wrong


Re: #yocto Remove hexdump from image #yocto

Josef Holzmayr
 

Am 19.11.2021 um 10:02 schrieb lucapirozzi via lists.yoctoproject.org:

Hi everyone,

I'm trying to remove some application, some of them packages and other being busybox parts.

I'm trying to remove hexdump from my image and I configured every busybox defconfig to have CONFIG_HEXDUMP and its REVERSE CONFIG to =n.

But I'm finding hexdump in my image filesystem nevertheless.
Check oe-pkgdata-util find-path in your build to find out which package/recipe to actually look at.


Greetz


Any help?

Thank you and Regards.


#yocto Remove hexdump from image #yocto

lucapirozzi@...
 

Hi everyone,

I'm trying to remove some application, some of them packages and other being busybox parts.

I'm trying to remove hexdump from my image and I configured every busybox defconfig to have CONFIG_HEXDUMP and its REVERSE CONFIG to =n.

But I'm finding hexdump in my image filesystem nevertheless.

Any help?

Thank you and Regards.


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

Kai Kang
 

From: Kai Kang <kai.kang@...>

Fix warning for apparmor:

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

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

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

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

INSANE_SKIP:${PN} = "ldflags"
--
2.17.1


[ANNOUNCEMENT] Yocto Project 3.3.4 (hardknott-25.0.4) is Released

Vineela
 

Hello,

 

We are pleased to announce the Yocto Project 3.3.4 (hardknott-25.0.4) Release is now available for download.

 

http://downloads.yoctoproject.org/releases/yocto/yocto-3.3.4/poky-hardknott-25.0.4.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.3.4/poky-hardknott-25.0.4.tar.bz2

 

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

 

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

 

Full Test Report:

 

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

 

Thank you for everyone's contributions to this release.

 

Vineela Tummalapalli

vineela.tummalapalli@...

Yocto Project Build and Release

 

 

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

yocto-3.3.4 Release Notes

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

 

 

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

Repositories/Downloads

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

 

Repository Name: poky

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

Branch: hardknott

Tag: yocto-3.3.4

Git Revision: c40ac16d79026169639f47be76a3f7b9d8b5178e

Release Artefact: poky-hardknott-25.0.4

sha: cbe13ef39105909ca13c6b6a84e4c66995e97a6c26e026b84046e5b8c5fd4a54

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.3.4/poky-hardknott-25.0.4.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.3.4/poky-hardknott-25.0.4.tar.bz2

 

Repository Name: openembedded-core

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

Branch: hardknott

Tag: 2021-04.4-hardknott

Git Revision: 0ca080a23c2770a15138f702d4c879bbd90ca360

Release Artefact: oecore-hardknott-25.0.4

sha: cc11201a8e4e80f4c776bc513d8442ffaf1dfd44fab7a72133da3aaabb967ff2

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.3.4/oecore-hardknott-25.0.4.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.3.4/oecore-hardknott-25.0.4.tar.bz2

 

Repository Name: meta-mingw

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

Branch: hardknott

Tag: yocto-3.3.4

Git Revision: 422b96cb2b6116442be1f40dfb5bd77447d1219e

Release Artefact: meta-mingw-hardknott-25.0.4

sha: eff7ca53ad2360faa277fa7def3eb618e3a0e66e6008a560bcf6839c85042bca

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.3.4/meta-mingw-hardknott-25.0.4.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.3.4/meta-mingw-hardknott-25.0.4.tar.bz2

 

Repository Name: meta-gplv2

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

Branch: hardknott

Tag: yocto-3.3.4

Git Revision: 9e119f333cc8f53bd3cf64326f826dbc6ce3db0f

Release Artefact: meta-gplv2-hardknott-25.0.4

sha: 9f273fc39082840baefb31de42efca6fe53f36679f665101b803df33d061c2a1

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.3.4/meta-gplv2-hardknott-25.0.4.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.3.4/meta-gplv2-hardknott-25.0.4.tar.bz2

 

Repository Name: bitbake

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

Branch: 1.50

Tag: 2021-04.4-hardknott

Git Revision: 0fe1a9e2d2e33f80d807cefc7a23df4a5f760c74

Release Artefact: bitbake-hardknott-25.0.4

sha: d689dc6647de2c880b814c0d5955b7d46c910e82221b0480eb7bd5fd4f455067

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.3.4/bitbake-hardknott-25.0.4.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.3.4/bitbake-hardknott-25.0.4.tar.bz2

 

Repository Name: yocto-docs

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

Branch: hardknott

Tag: yocto-3.3.4

Git Revision: e8e4539e1e812ea835192d1e35cc9992a43059ca

 

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

Contributors

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

Alexander Kanavin

Anibal Limon

Anuj Mittal

Armin Kuster

Bruce Ashfield

Caner Altinbasak

Chandana kalluri

Changqing Li

Chen Qi

Claudius Heine

Hongxu Jia

Jon Mason

Jose Quaresma

Joshua Watt

Kai Kang

Kenfe-Mickael Laventure

Kevin Hao

Khem Raj

Kiran Surendran

Konrad Weihmann

Mark Hatle

Markus Volk

Martin Jansa

Michael Halstead

Michael Opdenacker

Mingli Yu

Pablo Saavedra Rodi?o

Pgowda

Richard Purdie

Ross Burton

Sakib Sajal

Steve Sakoman

Thomas Perrot

Tom Pollard

Trevor Gamblin

William A. Kennington III

Yi Zhao

 

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

Known Issues

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

Bug 14622 - bsps-hw.bsps-hw.Test_Seek_bar_and_volume_control manual test case failure

 

 

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

Security Fixes

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

openssh: fix CVE-2021-41617

binutils: Fix CVE-2021-3530

ghostscript: Fix CVE-2021-3781

ncurses: fix CVE-2021-39537

vim: Backport fix for CVE-2021-3770

bind: Exclude CVE-2019-6470 from cve-check

qemu: fix CVE-2021-3682

systemd: fix CVE-2021-33910

connman: add CVE_PRODUCT

vim: fix CVEs

ffmpeg: fix CVE-2021-38114

tar: ignore node-tar CVEs

ffmpeg: fix CVE-2021-38171

go: Exclude CVE-2021-29923 from report list

flex: Add CVE-2019-6293 to exclusions for checks

tcl: Exclude CVE-2021-35331 from checks

bluez5: fix CVE-2021-0129

ffmpeg: fix CVE-2021-38291

squashfs-tools: fix CVE-2021-40153

mc: fix CVE-2021-36370

apr: Security fix for CVE-2021-35940

sqlite3: fix CVE-2021-36690

ruby: fix CVE-2021-31799

ruby: Security fixes for CVE-2021-31810/CVE-2021-32066

 

 

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

Fixes

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

build-appliance-image: Update to hardknott head revision

poky.conf: bump version for 3.3.4 hardknott release

ref-manual: migration-3.0: fix ref to removed variable

documentation: prepare for 3.3.4 release

bitbake: fetch/git: Handle github dropping git:// support

meta: bump HASHEQUIV_HASH_VERSION after RPM fix

bootchart2: Don't compile python modules

tzdata: upgrade 2021a -> 2021d

ca-certificates: update 20210119 -> 20211016

wireless-regdb: upgrade 2021.07.14 -> 2021.08.28

wireless-regdb: upgrade 2021.04.21 -> 2021.07.14

linux-firmware: upgrade 20210818 -> 20210919

linux-yocto/5.10: update to v5.10.75

linux-yocto/5.10: update to v5.10.74

linux-yocto/5.10: update to v5.10.73

strace: show test suite log on failure

waffle: convert to git, website is down

sstate: fix touching files inside pseudo

oe/utils: log exceptions in ThreadedWorker functions

testimage: fix unclosed testdata file

uninative: Upgrade to 3.4

poky.yaml: fedora33: add missing pkgs

reproducible_build: Work around caching issues

rpm: Deterministically set vendor macro entry

go: upgrade 1.16.7 -> 1.16.8

ruby: fix the reproducibility issue

linux-yocto/5.10: update to v5.10.70

linux-yocto/5.10: update to v5.10.69

oeqa/selftest/glibc: Handle incorrect encoding issuesin glibc test results

uninative: Upgrade to 3.3, support glibc 2.34

uninative: Improve glob to handle glibc 2.34

pseudo: Update with fcntl and glibc 2.34 fixes

nativesdk-pseudo: Fix to work with glibc 2.34 systems

pseudo: Fix to work with glibc 2.34 systems

gpgme: Use glibc provided closefrom API when available

m4: Do not use SIGSTKSZ

util-linux: disable raw

patch.bbclass: when the patch fails show more info on the fatal error

rng-tools: add systemd-udev-settle wants to service

python3: Add a fix for a make install race

libnewt: Use python3targetconfig to fix reproducibility issue

libxml2: Use python3targetconfig to fix reproducibility issue

oeqa/manual: Fix no longer valid URLs

multilib: Avoid sysroot race issues when multilib enabled

externalsrc: Fix a source date epoch race in reproducible builds

externalsrc: Work with reproducible_build

oeqa/selftest/bbtests: Add uuid to force build test

gobject-introspection: Don't write $HOME into scripts

mesa: Ensure megadrivers runtime mappings are deterministic

gnupg: Be deterministic about sendmail

package: Ensure pclist files are deterministic and don't use full paths

rpm: Ensure compression parallelism isn't coded into rpms

linux-yocto/5.4: update to v5.4.153

linux-yocto/5.4: update to v5.4.150

linux-yocto/5.4: update to v5.4.149

mesa: gallium/dri Make YUV formats we're going to emulate external-only

glibc: upgrade glibc-2.33 to latest version

bitbake: fetch2: clarify the command-no-found error message

bitbake: build: Make exception printing clearer

bitbake: bitbake-worker: Handle pseudo shutdown in Ctrl+C case

bitbake: build: Ensure python stdout/stderr is logged correctly

bitbake: bitbake-worker: Allow shutdown/database flush of pseudo server at task exit

bitbake: npmsw: Avoid race condition with multiple npm fetchers

bitbake: tests/runqueue: Ensure hashserv exits before deleting files

bitbake: fetch2/git: Use os.rename instead of mv

bitbake: fetch2/git: Avoid races over mirror tarball creation

bitbake: test/fetch: Update urls to match upstream branch name changes

scriptutils.py: Add check before deleting path

recipes-support/ptest-runner: Bump to v2.4.2

rm_work.bbclass: Fix for files starting with -

package_ipk: Use localdata store when signing packages

glew: Stop polluting /tmp during builds

wic: keep rootfs_size as integer

Update mailing list address

bitbake: build: Handle SystemExit in python tasks correctly

bitbake: build: Avoid duplicating logs in verbose mode

bitbake: process: Don't include logs in error message if piping them

bash: Ensure deterministic build

oeqa/buildproject: Ensure temp directories are cleaned up

oeqa/selftest/gotoolchain: Fix temp file cleanup

oeqa/qemurunner: Use oe._exit(), not sys.exit()

libsamplerate0: Set correct soname for 0.1.9

bzip2: Update soname for libbz2 1.0.8

pybootchart: Avoid divide by zero

expat: pull from github releases

yocto-bsp/5.10: update to v5.10.63

meta-yocto-bsp: Bump to the v5.10.55

local.conf.sample: Update sstate mirror entry with new hash equivalence setting

poky: Use SDKPATHINSTALL instead of SDKPATH

sstate: Avoid problems with recipes using SRCPV when fetching sstate

bitbake: runqueue/knotty: Improve UI handling of setscene task counting

bitbake: cookerdata: Show a readable error for invalid multiconfig name

bitbake: bitbake-worker: Improve error handling

bitbake: cooker/process: Fix typos in exiting message

bitbake: runqueue: Clean up task stats handling

bitbake: data_smart: Improve error display for handled exceptions

bitbake: cookerdata: Improve missing core layer error message

bitbake: cookerdata: Show error for no BBLAYERS in bblayers.conf

bitbake: tests/fetch2: Use our own git server for dtc test repo

linux-yocto/5.4: update to v5.4.144

linux-yocto/5.4: update to v5.4.143

systemtap: Fix headers issue with x86 and 5.13 headers

linux-yocto/5.10: update to v5.10.63

linux-yocto/5.10: update to v5.10.61

bitbake: build: Catch and error upon circular task references

bitbake: runqueue: Improve multiconfig deferred task issues

bitbake: cooker: Allow upstream for local hash equivalence server

bitbake: runqueue: Fix issues with multiconfig deferred task deadlock messages

bitbake: runqueue: Avoid deadlock avoidance task graph corruption


Re: [meta-raspberrypi][PATCH] linux-firmware-rpidistro: add branch in SRC_URI

Devendra Tewari
 

Thanks.

Em 18 de nov. de 2021, à(s) 18:17, Martin Jansa <martin.jansa@...> escreveu:


On Thu, Nov 18, 2021 at 9:01 PM Devendra Tewari <devendra.tewari@...> wrote:
Branch master has been renamed to buster. Also setting protocol to
https as GitHub is migrating away from unencrypted git protocol

Signed-off-by: Devendra Tewari <devendra.tewari@...>
---
 .../linux-firmware-rpidistro/linux-firmware-rpidistro_git.bb    | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-kernel/linux-firmware-rpidistro/linux-firmware-rpidistro_git.bb b/recipes-kernel/linux-firmware-rpidistro/linux-firmware-rpidistro_git.bb
index a091585..874e444 100644
--- a/recipes-kernel/linux-firmware-rpidistro/linux-firmware-rpidistro_git.bb
+++ b/recipes-kernel/linux-firmware-rpidistro/linux-firmware-rpidistro_git.bb
@@ -34,7 +34,7 @@ LIC_FILES_CHKSUM = "\
 NO_GENERIC_LICENSE[Firmware-broadcom_bcm43xx-rpidistro] = "LICENCE.broadcom_bcm43xx"
 NO_GENERIC_LICENSE[WHENCE] = "WHENCE"

-SRC_URI = "git://github.com/RPi-Distro/firmware-nonfree"
+SRC_URI = "git://github.com/RPi-Distro/firmware-nonfree;protocol=https;branch=buster"

 SRCREV = "83938f78ca2d5a0ffe0c223bb96d72ccc7b71ca5"
 PV = "20190114-1+rpt11"
--
2.33.1





Re: [meta-raspberrypi][PATCH] linux-firmware-rpidistro: add branch in SRC_URI

Martin Jansa
 

On Thu, Nov 18, 2021 at 9:01 PM Devendra Tewari <devendra.tewari@...> wrote:
Branch master has been renamed to buster. Also setting protocol to
https as GitHub is migrating away from unencrypted git protocol

Signed-off-by: Devendra Tewari <devendra.tewari@...>
---
 .../linux-firmware-rpidistro/linux-firmware-rpidistro_git.bb    | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-kernel/linux-firmware-rpidistro/linux-firmware-rpidistro_git.bb b/recipes-kernel/linux-firmware-rpidistro/linux-firmware-rpidistro_git.bb
index a091585..874e444 100644
--- a/recipes-kernel/linux-firmware-rpidistro/linux-firmware-rpidistro_git.bb
+++ b/recipes-kernel/linux-firmware-rpidistro/linux-firmware-rpidistro_git.bb
@@ -34,7 +34,7 @@ LIC_FILES_CHKSUM = "\
 NO_GENERIC_LICENSE[Firmware-broadcom_bcm43xx-rpidistro] = "LICENCE.broadcom_bcm43xx"
 NO_GENERIC_LICENSE[WHENCE] = "WHENCE"

-SRC_URI = "git://github.com/RPi-Distro/firmware-nonfree"
+SRC_URI = "git://github.com/RPi-Distro/firmware-nonfree;protocol=https;branch=buster"

 SRCREV = "83938f78ca2d5a0ffe0c223bb96d72ccc7b71ca5"
 PV = "20190114-1+rpt11"
--
2.33.1





Re: Building -native with clang

Joel Winarske
 

Thanks, I'll check it out.

This works:

DEPENDS += "\
    compiler-rt \
    libcxx \
    llvm \
    "

RUNTIME = "llvm"
TOOLCHAIN = "clang"
PREFERRED_PROVIDER:libgcc = "compiler-rt"

RUNTIME:class-native = "llvm"
TOOLCHAIN:class-native = "clang"
PREFERRED_PROVIDER:libgcc:class-native = "compiler-rt"


On Thu, Nov 18, 2021 at 12:04 PM Khem Raj <raj.khem@...> wrote:
Look into chromium recipe

On Thu, Nov 18, 2021 at 11:55 AM Joel Winarske <joel.winarske@...> wrote:
>
> How do I get a -native recipe to use clang-native?  I have this in my recipe, and target variant builds with clang:
>
> RUNTIME = "llvm"
> TOOLCHAIN = "clang"
> PREFERRED_PROVIDER:libgcc = "compiler-rt"
>
> All the environment variables are setup for gcc in the case of -native.  No sign of clang.
>
> This is with honister.
>
>
> Joel
>
>
>


Re: Building -native with clang

Khem Raj
 

Look into chromium recipe

On Thu, Nov 18, 2021 at 11:55 AM Joel Winarske <joel.winarske@...> wrote:

How do I get a -native recipe to use clang-native? I have this in my recipe, and target variant builds with clang:

RUNTIME = "llvm"
TOOLCHAIN = "clang"
PREFERRED_PROVIDER:libgcc = "compiler-rt"

All the environment variables are setup for gcc in the case of -native. No sign of clang.

This is with honister.


Joel



[meta-raspberrypi][PATCH] linux-firmware-rpidistro: add branch in SRC_URI

Devendra Tewari
 

Branch master has been renamed to buster. Also setting protocol to
https as GitHub is migrating away from unencrypted git protocol

Signed-off-by: Devendra Tewari <devendra.tewari@...>
---
.../linux-firmware-rpidistro/linux-firmware-rpidistro_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-kernel/linux-firmware-rpidistro/linux-firmware-rpidistro_git.bb b/recipes-kernel/linux-firmware-rpidistro/linux-firmware-rpidistro_git.bb
index a091585..874e444 100644
--- a/recipes-kernel/linux-firmware-rpidistro/linux-firmware-rpidistro_git.bb
+++ b/recipes-kernel/linux-firmware-rpidistro/linux-firmware-rpidistro_git.bb
@@ -34,7 +34,7 @@ LIC_FILES_CHKSUM = "\
NO_GENERIC_LICENSE[Firmware-broadcom_bcm43xx-rpidistro] = "LICENCE.broadcom_bcm43xx"
NO_GENERIC_LICENSE[WHENCE] = "WHENCE"

-SRC_URI = "git://github.com/RPi-Distro/firmware-nonfree"
+SRC_URI = "git://github.com/RPi-Distro/firmware-nonfree;protocol=https;branch=buster"

SRCREV = "83938f78ca2d5a0ffe0c223bb96d72ccc7b71ca5"
PV = "20190114-1+rpt11"
--
2.33.1


Building -native with clang

Joel Winarske
 

How do I get a -native recipe to use clang-native?  I have this in my recipe, and target variant builds with clang:

RUNTIME = "llvm"
TOOLCHAIN = "clang"
PREFERRED_PROVIDER:libgcc = "compiler-rt"

All the environment variables are setup for gcc in the case of -native.  No sign of clang.

This is with honister.


Joel


Minutes: Yocto Project Weekly Triage Meeting 11/18/2021

Trevor Gamblin
 

Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage

Attendees: Alexandre, Armin, Daiane, Jon, Randy, Richard, Ross, Saul, Stephen, Steve, Tim, Trevor

ARs:

- Richard to determine what infrastructure support/changes are needed for i586 tuning (see YP #14632)


Notes:

N/A

Medium+ 3.5 Unassigned Enhancements/Bugs: 73 (No change)

Medium+ 3.99 Unassigned Enhancements/Bugs: 39 (No change)

AB Bugs: 61 (Last week 62)


Re: QA notification for completed autobuilder build (yocto-3.1.12.rc1)

Teoh, Jay Shen
 

Hi all,

Intel and WR YP QA is planning for QA execution for YP build yocto-3.1.12.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 next Tuesday, Nov 23.

Thanks,
Jay

-----Original Message-----
From: yocto@... <yocto@...> On Behalf
Of Richard Purdie
Sent: Wednesday, 17 November, 2021 6:25 AM
To: <yocto@...> <yocto@...>
Cc: qa-build-notification <qa-build-notification@...>
Subject: [yocto] QA notification for completed autobuilder build (yocto-
3.1.12.rc1)

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


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


Build hash information:

bitbake: c0348de8121c3a842bf44906f7e2f79e93f7275b
meta-agl: 0406cbb235fb08ce9e6f9d07e64e0932b20050a9
meta-arm: ce535dfb96de4d2529f091d7d85a7172c626001c
meta-aws: 2f72301f5a73279c4d2f12fc6218876629666e06
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: 625da85e7b01b71cc310267b0ba7119eb139e9f7
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
meta-openembedded: 7889158dcd187546fc5e99fd81d0779cad3e8d17
oecore: 44b1970c40e9d73f6e63fb10cdc55837a26f5921
poky: 0839888394a6e42e96f9f0d201376eb38bc79b24



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


abhi <abhishek.kumar@...>
 

hi sir,

i am working on yocto ,i created one core-image-base inside that image i want to set logo on u-boot and kernel side ,i added psplash also in local.conf (IMAGE_FEATURES = "psplash")  .
but default logo even not coming please tell how set splash screen logo in yocto side, bellow error i got it will be helpfull for u.

thanks in advance


Re: [meta-rockchip][PATCH] kernel: linux-yocto: fix broken Ethernet MAC controller on RK3399 on 5.14 >= version <= 5.14.11

Quentin Schulz
 

Hi Khem,

On Tue, Nov 16, 2021 at 10:50:13AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 10:03 AM Quentin Schulz <foss@...> wrote:



On November 16, 2021 6:45:05 PM GMT+01:00, Khem Raj <raj.khem@...> wrote:
On Tue, Nov 16, 2021 at 9:12 AM Quentin Schulz <
quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:08:41AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 9:04 AM Quentin Schulz
<quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:00:42AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 7:52 AM Quentin Schulz
<quentin.schulz@...> wrote:

From Linux kernel v5.14 to v5.14.11 (both included), the Ethernet
MAC
controller found on RK3399 is not working.

A fix is available in v5.14.12 and later (available also in v5.15)
which is provided here and applied to linux-yocto source tree if
linux-yocto version is of the impacted ones.

The conditional patching is unfortunately required because
Honister 3.4
has linux-yocto v5.14.9 and Honister 3.4.1 will have at least
linux-yocto v5.14.14.
Patching piece below looks quite a bit.
lets just fix v5.14.14 and dont worry about 3.4
v5.14.14 is already fixed. The only release currently is 3.4 and I hit
that issue, hence the patch.
I assume not everybody is updating to 3.4.1 when it's out, I've seen
people running behind dot releases.
What's bothering you?
once dot release is out then thats whats maintained not the original
release since they are incremental.
the anon python to apply a patch. Can you explain why we want to patch
applied this way ?
I could define a python function and use it like this:
SRC_URI:append:rk3399 = "${@rk3399_fix_mac(d)}"

Would that work better for you?

I am not yet convinced why should we have such version specific patch
If you could explain what's *really* bothering you, I could try to find a proper explanation or agree with you but it's a bit too vague to me right now. Anyway, I'll do some guesses in the next paragraphs.

Because Ethernet does not work for all RK3399-based boards in the latest and only release of Honister?
meta-rockchip does not have honister branch for now. So it expects
master to keep working with honister for now. kernel upgrades are
already committed into honister branch on meta-yocto-bsps so fix it
already available in latest honister
branch and will be in imminent point release soon as well.
meta-rockchip does not have a honister branch for now because it is
still working with master branch from OE-Core. This patch does not break
this behaviour.


meta-rockchip is the BSP layer for Rockchip based devices, if not there, where should I put this patch?

Or are we just going to say "Ethernet does not work, we know" to people asking instead of having this patch in? Obviously you could tell them to upgrade their oe-core/poky git repo to rolling honister or 3.4.1 once it's out but having this patch in avoid those questions.
I would say yes, document it as that of a known issue and possible fix
Do I add a "known issues" to the README then? Or where am I supposed to
add this piece of information were this patch not merged?

if someone is using exact point release. They might have snapshotted
meta-rockpi too and in that case it will be easy for them to carry a
local patch if needed.
vesion specific patching would also be setting a not so desired
patching practice, so I am trying to avoid it if we can.
I think we both understand each other's stance and I've no additional
arguments to give, so it'll be up to the maintainer(s) which is
officially Trevor, but maybe I am not aware of other unofficial
maintainers :)

In any case, I can have this patch in my own vendor BSP but since it
applies to all RK3399-based devices, I thought it'd be nicer to have it
in upstream meta-rockchip than in a vendor BSP unrelated to the boards
one's using.

@Trevor/maintainers, let us know what's your opinion on this so I know
if I should send a v2 using inline python function for SRC_URI instead
of using the anonymous python function.

Cheers,
Quentin


Re: [meta-rockchip][PATCH] kernel: linux-yocto: fix broken Ethernet MAC controller on RK3399 on 5.14 >= version <= 5.14.11

Quentin Schulz
 

On Tue, Nov 16, 2021 at 09:08:41AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 9:04 AM Quentin Schulz
<quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:00:42AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 7:52 AM Quentin Schulz
<quentin.schulz@...> wrote:

From Linux kernel v5.14 to v5.14.11 (both included), the Ethernet MAC
controller found on RK3399 is not working.

A fix is available in v5.14.12 and later (available also in v5.15)
which is provided here and applied to linux-yocto source tree if
linux-yocto version is of the impacted ones.

The conditional patching is unfortunately required because Honister 3.4
has linux-yocto v5.14.9 and Honister 3.4.1 will have at least
linux-yocto v5.14.14.
Patching piece below looks quite a bit.
lets just fix v5.14.14 and dont worry about 3.4
v5.14.14 is already fixed. The only release currently is 3.4 and I hit
that issue, hence the patch.
I assume not everybody is updating to 3.4.1 when it's out, I've seen
people running behind dot releases.
What's bothering you?
once dot release is out then thats whats maintained not the original
release since they are incremental.
the anon python to apply a patch. Can you explain why we want to patch
applied this way ?
I could define a python function and use it like this:
SRC_URI:append:rk3399 = "${@rk3399_fix_mac(d)}"

Would that work better for you?

Cheers,
Quentin


Re: [meta-rockchip][PATCH] kernel: linux-yocto: fix broken Ethernet MAC controller on RK3399 on 5.14 >= version <= 5.14.11

Quentin Schulz
 

On Tue, Nov 16, 2021 at 09:00:42AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 7:52 AM Quentin Schulz
<quentin.schulz@...> wrote:

From Linux kernel v5.14 to v5.14.11 (both included), the Ethernet MAC
controller found on RK3399 is not working.

A fix is available in v5.14.12 and later (available also in v5.15)
which is provided here and applied to linux-yocto source tree if
linux-yocto version is of the impacted ones.

The conditional patching is unfortunately required because Honister 3.4
has linux-yocto v5.14.9 and Honister 3.4.1 will have at least
linux-yocto v5.14.14.
Patching piece below looks quite a bit.
lets just fix v5.14.14 and dont worry about 3.4
v5.14.14 is already fixed. The only release currently is 3.4 and I hit
that issue, hence the patch.
I assume not everybody is updating to 3.4.1 when it's out, I've seen
people running behind dot releases.
What's bothering you?

Cheers,
Quentin


NFS under yocto

Monsees, Steven C (US)
 

 

Current yocto build is based on zeus…

We have one board running Yocto Embedded linux that is sharing a drive partition via NFS.

Another board is mounting the NFS share and has a few processes that can write data to the drive.

We are seeing conditions were concurrent writes (two client processes) appear to result in “Stale File Handles”.

The drive partition is using the NTFS file system.

 

We are wondering if there are any issues in the NFS Server or Client that could be causing these “Stale File Handles”.

We have tried to change some of the options used to mount the NFS share.

Are there any options in how the location is shared that we should try?

 

Anyone hear about or experienced similar issues ?

 

Thanks,

Steve