Date   

Canceled: OpenEmbedded Happy Hour December 29

Denys Dmytriyenko
 

Hi,

The next OpenEmbedded Happy Hour is being canceled due to the Holidays and
since we had the last one on December 3. The next Happy Hour will take place
on January 26 2022:

https://www.openembedded.org/wiki/Calendar

--
Regards,
Denys Dmytriyenko <denis@...>
PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964
Fingerprint: 25FC E4A5 8A72 2F69 1186 6D76 4209 0272 9A92 C964


Minutes: Yocto Project Weekly Triage Meeting 12/16/2021

Trevor Gamblin
 

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

Attendees: Armin, Jon, Joshua, Michael, Randy, Richard, Ryan, Saul, Stephen, Steve, Trevor, Valerii

ARs:

- Randy to bump the M1s in the AB-INT list

- Randy to remove AB-INT tempfs from the whiteboard field

- Randy to move Medium+ M1s to later milestones

- Everyone to review their Old Milestone bugs and move to new milestones or close

Notes:

No triage meeting on December 30th

Medium+ 3.5 Unassigned Enhancements/Bugs: 76 (Last week 75)

Medium+ 3.99 Unassigned Enhancements/Bugs: 38 (Last week 38)

AB Bugs: 73 (Last week 67)


Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.1.13.rc1)

Teoh, Jay Shen
 

Hi all,

Intel and WR YP QA is planning for QA execution for YP build yocto-3.1.13.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 Monday, Dec 20.

Thanks,
Jay

-----Original Message-----
From: qa-build-notification@... <qa-build-
notification@...> On Behalf Of Richard Purdie
Sent: Wednesday, 15 December, 2021 3:40 PM
To: <yocto@...> <yocto@...>
Cc: qa-build-notification <qa-build-notification@...>
Subject: [qa-build-notification] QA notification for completed autobuilder build
(yocto-3.1.13.rc1)

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


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


Build hash information:

bitbake: f18b65d0b9a6b983d53bde491e1bf2ca56949444
meta-agl: 6d1ab9f3bb270a773ec5d2f7c8c856796833b559
meta-arm: ce535dfb96de4d2529f091d7d85a7172c626001c
meta-aws: 9979cfa676105cb68cfadfdaeabf044d7c919319
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: 87984115eb6ed1a4c17204629dcb100f6b76fe82
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
meta-openembedded: 69f94af4d91215e7d4e225bab54bf3bcfee42f1c
oecore: 90a07178ea26be453d101c2e8b33d3a0f437635d
poky: 795339092f87672e4f68e4d3bc4cfd0e252d1831



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







Yocto Technical Team Minutes, Engineering Sync, for December 14, 2021

Trevor Woerner
 

Yocto Technical Team Minutes, Engineering Sync, for December 14, 2021
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner, Stephen Jolley, Bruce Ashfield, Daiane, Jan-Simon Möller,
Jon Mason, Joshua Watt, Saul Wold, Steve Sakoman, Randy MacLeod, Richard
Purdie, Scott Murray, Rephael C, Peter Kjellerstedt, Ross Burton, Michael
Opdenacker, Armin Kuster, Nathan Glimsdale, Ryan Eatmon

== project status ==
- 3.5 M1 (kirkstone) in QA
- 3.1.13 (dunfell) to be built this week
- maintenance for AB, updating SSDs and updating distros, next week (Dec 20-24)
- significant improvements to patch count, some changes might affect other layers
- CVE metrics improved for dunfell and master
- rising AB-int issues (new high!)

== discussion ==
RP: looked at more patches last week. removed some patches related to a MIPS
platform (support for which was also removed from the latest kernel, see
https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.16-Drops-MIPS-
Netlogic). these patches were never added to upstream binutils. an SH4 gdb
patch was also removed, not sure if it even works anymore. if users need
these things, they can be re-introduced in separate layers if required,
but not appropriate for oe-core going forward. Ross wins the award for
most invasive change, and changes most likely to require changes in
other layers, but these are good changes. seeing good trends: 50 patches
removed, and 50 patched moved out of pending state. i’m still working
with upstream gcc to get some patches merged and am still hoping to get
some libtool patches upstream too.

RP: re: AB-int issues: there is a recurring bitbake selftest issue with the
runqueue tests that does have a fix ready. also lttng: there appear to
be a number of tools issues going on but all logged as one bug. upstream
has fixed some of the original bugs we reported, but there are some other
things. it all appears to have started around june

RP: AB downtime next week. there’s never a good time to do it. reimaging of most of the cluster. Michael has permission to replace all the OSes on all the workers (bring in new ones, remove old ones). it’s a good time to bring in new distros and get rid of older versions. for all we know the AB may never work again! (lol). if you have anything that needs to be preserved make sure to let us know.

RP: it also means that if we’re going to have a 3.1.13 release, it has to be
this week.
SS: i’m ready, there is a small set of patches
RP: so the plan is to get those in, then do the build?
SS: yes. i don’t think there’s anything controversial there at all
RP: there’s a chance the parts might not arrive in time, so the update to
the AB might get delayed

Randy: if we upgrade all the AB to SSDs then we won’t have a control to see
how things go, other than historical data? does everyone only use SSD? are
magnetic disks still important?
SS: i’ve been SSD-only for a couple years now
RP: conversely i only use spinning rust
JPEW: i would expect that the intersection of people doing things as extreme
as the AB and still using spinning disks is confined to just the AB
Randy: you would be wrong (lol). at least half of WR is still using magnetic
disks. however we do plan to upgrade.
RP: i understand the desire to have a control, but that would add to the
maintenance burden. we’ll have to see how it goes. we have 2 performance
testing workers as well, one is running CentOS 7 and the other is running
Ubuntu 16.04; those will also need upgrading as well (we’ve been putting
it off for too long now). so we might end up with 2 more performance
workers (that will run in parallel with the existing 2) or the existing
ones might just get replaced. it’s up to Michael
Randy: what about the ARM worker, any sign of that machine arriving?
RP: there’s talk of it, but getting stuff into the US is not easy
Saul: is anyone talking to Ampere?
RP: the people involved are the ARM people, so they know what they’re doing
Randy: will the ARM worker get an SSD as well?
RP: it think it already has one. if it doesn’t then it will
Ross: the ARM worker is pretty old hardware, unfortunately
RP: we have 2, one is older but bulletproof. the other one is faster but has a
tendency to report CPU temps that are high

JPEW: i sent an RFC to switch the bitbake-worker to asyncio
RP: i had a look. i hadn’t thought of using asyncio in bitbake-worker
because generally it is one of the more self-contained bits of bitbake
that generally actually works and i had wanted to leave it alone. the
patch adds more lines than it removes. is it an improvement?
JPEW: given what it’s doing, i don’t think it’s going to be more
efficient. most of the time it sits waiting for things. the big advantage
would be the maintainability. asycnio is easier to read than the polling
loop it was doing. the adding of lines might just be my way of writing
code.
RP: i don’t object to it as such. if *i* had done the conversion then
i could read that code more easily, however, since i didn’t do the
conversion, it makes maintainability harder for me. that’s not a
criticism of the work itself. the diff is too big, maybe easier to just
look at the updated code
JPEW: yes the diff is worthless. also, we could simplify it even more if we
slightly changed the protocol between bitbake-worker and bitbake-server.
would fit better with how asyncio works and what’s already included
in asyncio (i.e. asyncio already knows how to hande reading text
line-by-line, but we do a tagged XML thing, which i had to write
explicitly). if we change it to be more like the hashserv protocol
(newline-delimited JSON) then that would fit very well with asyncio. that
would reduce the size
RP: i think the data (that goes over the bitbake-worker to bitbake-server
link) can have newlines in it, so we’d need an escape mechanism
JPEW: yes, it’s pickled data. it wouldn’t have to be newlines, you could
split on any character
RP: also, there are some lines removing some multiprocessing locking, is that
still safe for workers that call into multiprocessing?
JPEW: the lock was never used in bitbake-worker itself, just the child
processes. so i moved it to the child processes. the child processes have
a pipe to bitbake-worker and i left the lock in the child process. so if
they’re multithreaded (or whatever) they still have a lock when they
write into the parent process. but each of them has a dedicated pipe into
bitbake-worker parent process, so that doesn’t need locking
RP: yes, fair enough. i need to look at the final code and think about it some
more

RP: i’m worried about the bitbake server process (i.e. not the worker but
the cooker). i have a pile of bugs but the general theme is: someone
presses Ctrl-C and bitbake is off doing something else and doesn’t
respond. in general (by design) we tend to defer things off (tasks are run
by bitbake-worker and not bitbake itself) the trouble is once the parsing
occurs in sub-processes it can can starve the connection handling. i’m
worried about the threading model (or lack thereof) in our design. there
are 2 types of commands that can be run against the server: synchronous
and asynchronous. but if something goes wrong in some of those synchronous
commands then you can’t even send a stop event to the server. asyncio
doesn’t necessarily help us with any of this stuff
JPEW: in order for asycio to help, everything has to be done asynchronously.
e.g. long-running tasks have to punt it to a thread (if it’s not I/O
bound)
RP: asyncio probably isn’t going to be the answer here, we might have to
push some of this out to a separate cooker thread with the server running
in its own thread and handling the actual UI and commands (etc) separately
JPEW: we’ll probably need a hybrid approach: asyncio for the main loop, and
long-running stuff in a thread
RP: it’s one of the bigger problems we have with bitbake right now. if
anyone has any ideas…

RP: re: meetings over the holidays. i’m guessing we’ll cancel meetings on
the 28th, and most will be back by the 4th of January? will enough people
be around for a meeting on the 21st?
<several>: i’ll be around
RP: okay, we’ll cancel the 28th and keep the others

Randy: i heard that someone got the terminal working in phosh? has anyone else
played with phosh and got it working?
JPEW: yes, mostly working. you can download the daily build
Randy: i’ll give it a try shortly. is it something we’ll keep until after
3.5? or are we going to rip out sato and replace it with phosh for this
release?
JPEW: oh no, not this release
RP: that’s a bad idea. we’ll run with sato for the LTS

RP: any other patches in oe-core that we should be doing things with? we
have some good success cases (e.g. the puzzles app in sato, binutils,
gdb). tcp-wrappers is appearing on my radar; upstream is dead and we’re
carrying about 15 patches. also the musl systemd patches need attention
ScottM: the two people who would care are not on this call
Ross: i think there’s been some improvement to systemd accepting musl
patches
ScottM: maybe alpine would drive this issue, but maybe not
RP: there are 2 sets of issues with systemd and musl: 1) headers issue (which
i think is relatively work-around-able) and i think systemd is willing to
negotiate on some of those patches 2) pieces of c library are missing and
by patching them out causes security holes, therefore we probably won’t
see systemd accepting those. systemd has made it quite clear that they
want to rely on those libc features and they’re simply not there in musl
(as is my understanding)
ScottM: they’re quite vocal about being fine with being very linux-centric
RP: i want to get this done early in the cycle, rather than waiting for the
week before feature-freeze


Re: spdx: Extending SPDX SBOMs for SDKs

Joshua Watt
 

On Wed, Dec 15, 2021 at 3:33 PM Andres Beltran
<abeltran@...> wrote:

+ Joshua, Saul

On 12/6/2021 6:54 PM, Andres Beltran wrote:

Hello,


I've been working on extending SPDX SBOMs for SDKs. In poky/meta/classes/create-spdx.bbclass I added:



do_populate_sdk[recrdeptask] += "do_create_spdx do_create_runtime_spdx"



I ran into a dependency loop when I try to build an SDK that contains nativesdk-clang (it works fine for other SDKs):



ERROR:

Dependency loop #1 found:

Task mc:lnx-sdk:/__w/1/s/sources/poky/../meta-clang/recipes-devtools/clang/clang-crosssdk_git.bb:do_create_spdx (dependent Tasks ['glibc_2.31.bb:do_create_spdx', 'binutils-crosssdk_2.34.bb:do_create_spdx', 'clang_git.bb:do_create_spdx', 'quilt-native_0.66.bb:do_populate_sysroot', 'nativesdk-clang-glue.bb:do_create_spdx'])



Task mc:lnx-sdk:virtual:nativesdk:/__w/1/s/sources/poky/../meta-clang/recipes-devtools/clang/clang_git.bb:do_create_spdx (dependent Tasks ['clang_git.bb:do_packagedata', 'cmake-native_3.16.5.bb:do_create_spdx', 'swig_3.0.12.bb:do_create_spdx', 'libedit_20191231-3.1.bb:do_create_spdx', 'binutils-crosssdk_2.34.bb:do_create_spdx', 'chrpath_0.16.bb:do_create_spdx', 'libffi_3.3.bb:do_create_spdx', 'clang-crosssdk_git.bb:do_create_spdx', 'zlib_1.2.11.bb:do_create_spdx', 'clang_git.bb:do_package', 'python3_3.8.2.bb:do_create_spdx', 'libxml2_2.9.10.bb:do_create_spdx', 'python3_3.8.2.bb:do_create_spdx', 'pkgconfig_git.bb:do_create_spdx', 'binutils_2.34.bb:do_create_spdx', 'quilt-native_0.66.bb:do_populate_sysroot', 'libedit_20191231-3.1.bb:do_create_spdx', 'libxml2_2.9.10.bb:do_create_spdx', 'ninja_1.10.0.bb:do_create_spdx'])



Task mc:lnx-sdk:/__w/1/s/sources/poky/../meta-clang/recipes-devtools/clang/nativesdk-clang-glue.bb:do_create_spdx (dependent Tasks ['gcc-runtime_9.3.bb:do_create_spdx', 'glibc_2.31.bb:do_create_spdx', 'nativesdk-clang-glue.bb:do_package', 'gcc-crosssdk_9.3.bb:do_create_spdx', 'chrpath_0.16.bb:do_create_spdx', 'quilt-native_0.66.bb:do_populate_sysroot', 'nativesdk-clang-glue.bb:do_packagedata', 'clang_git.bb:do_create_spdx'])
Looks like the loop is:
nativesdk-clang-glue.bb:do_create_spdx ->
clang_git.bb:do_create_spdx -> clang-crosssdk_git.bb:do_create_spdx ->
nativesdk-clang-glue.bb:do_create_spdx

I don't know enough about the clang recipes to be able to help you
much beyond that however




Any help on this would be appreciated.



Thanks,

Andres Beltran




Re: spdx: Extending SPDX SBOMs for SDKs

Andres Beltran
 

+ Joshua, Saul

On 12/6/2021 6:54 PM, Andres Beltran wrote:

Hello,


I've been working on extending SPDX SBOMs for SDKs. In poky/meta/classes/create-spdx.bbclass I added:

 

do_populate_sdk[recrdeptask] += "do_create_spdx do_create_runtime_spdx"

 

I ran into a dependency loop when I try to build an SDK that contains nativesdk-clang (it works fine for other SDKs):

 

ERROR:

Dependency loop #1 found:

Task mc:lnx-sdk:/__w/1/s/sources/poky/../meta-clang/recipes-devtools/clang/clang-crosssdk_git.bb:do_create_spdx (dependent Tasks ['glibc_2.31.bb:do_create_spdx', 'binutils-crosssdk_2.34.bb:do_create_spdx', 'clang_git.bb:do_create_spdx', 'quilt-native_0.66.bb:do_populate_sysroot', 'nativesdk-clang-glue.bb:do_create_spdx'])

 

Task mc:lnx-sdk:virtual:nativesdk:/__w/1/s/sources/poky/../meta-clang/recipes-devtools/clang/clang_git.bb:do_create_spdx (dependent Tasks ['clang_git.bb:do_packagedata', 'cmake-native_3.16.5.bb:do_create_spdx', 'swig_3.0.12.bb:do_create_spdx', 'libedit_20191231-3.1.bb:do_create_spdx', 'binutils-crosssdk_2.34.bb:do_create_spdx', 'chrpath_0.16.bb:do_create_spdx', 'libffi_3.3.bb:do_create_spdx', 'clang-crosssdk_git.bb:do_create_spdx', 'zlib_1.2.11.bb:do_create_spdx', 'clang_git.bb:do_package', 'python3_3.8.2.bb:do_create_spdx', 'libxml2_2.9.10.bb:do_create_spdx', 'python3_3.8.2.bb:do_create_spdx', 'pkgconfig_git.bb:do_create_spdx', 'binutils_2.34.bb:do_create_spdx', 'quilt-native_0.66.bb:do_populate_sysroot', 'libedit_20191231-3.1.bb:do_create_spdx', 'libxml2_2.9.10.bb:do_create_spdx', 'ninja_1.10.0.bb:do_create_spdx'])

 

Task mc:lnx-sdk:/__w/1/s/sources/poky/../meta-clang/recipes-devtools/clang/nativesdk-clang-glue.bb:do_create_spdx (dependent Tasks ['gcc-runtime_9.3.bb:do_create_spdx', 'glibc_2.31.bb:do_create_spdx', 'nativesdk-clang-glue.bb:do_package', 'gcc-crosssdk_9.3.bb:do_create_spdx', 'chrpath_0.16.bb:do_create_spdx', 'quilt-native_0.66.bb:do_populate_sysroot', 'nativesdk-clang-glue.bb:do_packagedata', 'clang_git.bb:do_create_spdx'])

 

Any help on this would be appreciated.

 

Thanks,

Andres Beltran





Re: [meta-rockchip] [PATCH v2] trusted-firmware-a: replace baudrate with the one specified in machine conf

Trevor Woerner
 

On Wed 2021-12-15 @ 04:20:47 PM, Quentin Schulz wrote:
Hi Khem,

On Tue, Dec 14, 2021 at 10:11:54AM -0800, Khem Raj wrote:
On Tue, Dec 14, 2021 at 3:39 AM Quentin Schulz
<quentin.schulz@...> wrote:

Not all Rockchip boards have their console running at 1500000 baud in
U-Boot and the kernel. Such is the case for puma-haikou RK3399-based
SoM+Carrierboard.

In order to prepare for the addition of puma-haikou to meta-rockchip,
let's replace the baudrate in TF-A by the one defined in the machine
conf file in the RK_CONSOLE_BAUD variable.

Cc: Quentin Schulz <foss+yocto@...>
Signed-off-by: Quentin Schulz <quentin.schulz@...>
---

v2: use a less restrictive regular expression

.../files/serial-console-baudrate.patch | 36 -------------------
.../trusted-firmware-a_%.bbappend | 6 +++-
2 files changed, 5 insertions(+), 37 deletions(-)
delete mode 100644 recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch

diff --git a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
deleted file mode 100644
index 2d6e9bf..0000000
--- a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-From 840d6b6420e1fd8cdf6e4de7fa58a6f8de151622 Mon Sep 17 00:00:00 2001
-From: Yann Dirson <yann@...>
-Date: Tue, 6 Apr 2021 17:28:45 +0200
-Subject: [PATCH] Set serial console baudrate back to 1500000.
-Upstream-Status: Inappropriate[other]
-
-TF-A runs between two u-boot stages which both uses 1500000 baud, it
-just makes no sense to use the same UART at a different rate.
-
-This effectively reverts part of 0c05748bdebfad9fa43a80962186438bb8fbce62.
-Main reason for that change stated in https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.trustedfirmware.org_T762&d=DwIBaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=MGuJiAJcTH-5vXWFahwY8w58v88VHX-B3gl_Qbo3NSRaMXS1EfPbxRWECgCDt3wO&s=P_BZb0-FTKKpmyBRgwgtL7OgfLI_iSC_nn_FBSQXE8o&e=
-is ChromeOS compatibility.
-
-Looks like this patch may become unnecessary in the future, when
-u-boot and TF-A get to communicate this value.
-
----
- plat/rockchip/rk3399/rk3399_def.h | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h
-index ba83242eb..8d6ecfbe6 100644
---- a/plat/rockchip/rk3399/rk3399_def.h
-+++ b/plat/rockchip/rk3399/rk3399_def.h
-@@ -17,7 +17,7 @@
- /**************************************************************************
- * UART related constants
- **************************************************************************/
--#define RK3399_BAUDRATE 115200
-+#define RK3399_BAUDRATE 1500000
- #define RK3399_UART_CLOCK 24000000
-
- /******************************************************************************
---
-2.30.2
-
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index 513cea1..07fae1e 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -7,7 +7,6 @@ COMPATIBLE_MACHINE:append:rk3328 = "|rk3328"

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
SRC_URI += "\
- file://serial-console-baudrate.patch \
file://0001-dram-Fix-build-with-gcc-11.patch \
file://0001-plat_macros.S-Use-compatible-.asciz-asm-directive.patch \
file://0001-pmu-Do-not-mark-already-defined-functions-as-weak.patch \
@@ -19,3 +18,8 @@ SRC_URI += "\
# this needs fixing until then use gcc
TOOLCHAIN:rk3399 = "gcc"

+fixup_rk3399_baudrate() {
+ sed -i "s/#define RK3399_BAUDRATE\s\+.*/#define RK3399_BAUDRATE ${RK_CONSOLE_BAUD}/" ${S}/plat/rockchip/rk3399/rk3399_def.h
+}
+
+do_patch[postfuncs] += "fixup_rk3399_baudrate"
perhaps applying the sed expression via do_configure:prepend() is simple ?
and maybe make it rk3399 specific with do_configure:prepend:rk3399
It is effectively patching the sources, and I'd personally expect
sources to not be changed after running -c do_patch for a recipe.
I don't have strong feelings either way, but it does feel more like a patching
operation than a configuration one.


[dunfell] hidden files/folders in WORKDIR

Joel Winarske
 

I'm finding that if I create files/folders (prefixed with '.') in WORKDIR, they don't get cleaned up with INHERIT += "rm_work".

Is this a feature or a bug?


Re: [oe] Help with Inclusive Language in OpenEmbedded/Yocto Project

Saul Wold
 

On 12/6/21 17:01, Jon Mason wrote:
This email is a follow-up from the session held on Friday at the
OpenEmbedded Developer's Virtual Meeting (see
https://www.openembedded.org/wiki/OEDVM_Nov_2021)
The session was not recorded, but the slides can be found at
https://docs.google.com/presentation/d/146ueVVTMeA8JI43wqv5kFmdYEygqqmfGH0z1VRL2bDA/edit?usp=sharing
The outcome from the discussion was that inclusive language changes
are something that we want to accomplish in the kirkstone release
timeframe (with an exception for the "master" branch name, which will
be handled at a future date).
There has already been a pass at collecting the needed changes at
https://wiki.yoctoproject.org/wiki/Inclusive_language
This is not as simple as a find/replace of offending words. There is
a desire for backward compatibility or to provide some kind of "you
want X, which is now Y" (which complicates things).
The intention of this email is to see who is interested in helping
out. Once we know how many people are available and what time frames,
we can plan out a roadmap. So, please email me (or respond to this
thread publicly) and I'll add you to the list. There will then be a
follow-up zoom call in the next week or so to plan out the roadmap.
I am interested in helping out also.

Another low hanging item might be changing the names of patches that include the offensive terms like the following (which I will add to the wiki:
meta-openembedded/meta-oe/recipes-graphics/lxdm/lxdm/0001-lxdm.conf.in-blacklist-root-for-release-images.patch
meta-openembedded/meta-oe/recipes-support/multipath-tools/files/0022-RH-Remove-the-property-blacklist-exception-builtin.patch
oe-core/meta/recipes-extended/tcp-wrappers/tcp-wrappers-7.6/11_tcpd_blacklist.patch
oe-core/meta/recipes-core/udev/udev-extraconf/mount.blacklist
Can't really rename this one or we rename it in oe-core but it gets named back on the installed system.

meta-secure-core/meta-integrity/files/ima_signing_blacklist
Same as above

meta-secure-core/meta-efi-secure-boot/recipes-bsp/efitools/efitools/Fix-the-wrong-dependency-for-blacklist.esl.patch

We would have to re-generate the patches to have the subject match the fixed language.

Sau!


We will document the roadmap and everything else on the YP wiki page above.
Questions and comments are welcome, but not interested in debating the
necessity or timeframe of this task. It has already been decided.
Thanks,
Jon


Re: [meta-rockchip] [PATCH v2] trusted-firmware-a: replace baudrate with the one specified in machine conf

Khem Raj
 

On Wed, Dec 15, 2021 at 7:20 AM Quentin Schulz
<quentin.schulz@...> wrote:

Hi Khem,

On Tue, Dec 14, 2021 at 10:11:54AM -0800, Khem Raj wrote:
On Tue, Dec 14, 2021 at 3:39 AM Quentin Schulz
<quentin.schulz@...> wrote:

Not all Rockchip boards have their console running at 1500000 baud in
U-Boot and the kernel. Such is the case for puma-haikou RK3399-based
SoM+Carrierboard.

In order to prepare for the addition of puma-haikou to meta-rockchip,
let's replace the baudrate in TF-A by the one defined in the machine
conf file in the RK_CONSOLE_BAUD variable.

Cc: Quentin Schulz <foss+yocto@...>
Signed-off-by: Quentin Schulz <quentin.schulz@...>
---

v2: use a less restrictive regular expression

.../files/serial-console-baudrate.patch | 36 -------------------
.../trusted-firmware-a_%.bbappend | 6 +++-
2 files changed, 5 insertions(+), 37 deletions(-)
delete mode 100644 recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch

diff --git a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
deleted file mode 100644
index 2d6e9bf..0000000
--- a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-From 840d6b6420e1fd8cdf6e4de7fa58a6f8de151622 Mon Sep 17 00:00:00 2001
-From: Yann Dirson <yann@...>
-Date: Tue, 6 Apr 2021 17:28:45 +0200
-Subject: [PATCH] Set serial console baudrate back to 1500000.
-Upstream-Status: Inappropriate[other]
-
-TF-A runs between two u-boot stages which both uses 1500000 baud, it
-just makes no sense to use the same UART at a different rate.
-
-This effectively reverts part of 0c05748bdebfad9fa43a80962186438bb8fbce62.
-Main reason for that change stated in https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.trustedfirmware.org_T762&d=DwIBaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=MGuJiAJcTH-5vXWFahwY8w58v88VHX-B3gl_Qbo3NSRaMXS1EfPbxRWECgCDt3wO&s=P_BZb0-FTKKpmyBRgwgtL7OgfLI_iSC_nn_FBSQXE8o&e=
-is ChromeOS compatibility.
-
-Looks like this patch may become unnecessary in the future, when
-u-boot and TF-A get to communicate this value.
-
----
- plat/rockchip/rk3399/rk3399_def.h | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h
-index ba83242eb..8d6ecfbe6 100644
---- a/plat/rockchip/rk3399/rk3399_def.h
-+++ b/plat/rockchip/rk3399/rk3399_def.h
-@@ -17,7 +17,7 @@
- /**************************************************************************
- * UART related constants
- **************************************************************************/
--#define RK3399_BAUDRATE 115200
-+#define RK3399_BAUDRATE 1500000
- #define RK3399_UART_CLOCK 24000000
-
- /******************************************************************************
---
-2.30.2
-
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index 513cea1..07fae1e 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -7,7 +7,6 @@ COMPATIBLE_MACHINE:append:rk3328 = "|rk3328"

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
SRC_URI += "\
- file://serial-console-baudrate.patch \
file://0001-dram-Fix-build-with-gcc-11.patch \
file://0001-plat_macros.S-Use-compatible-.asciz-asm-directive.patch \
file://0001-pmu-Do-not-mark-already-defined-functions-as-weak.patch \
@@ -19,3 +18,8 @@ SRC_URI += "\
# this needs fixing until then use gcc
TOOLCHAIN:rk3399 = "gcc"

+fixup_rk3399_baudrate() {
+ sed -i "s/#define RK3399_BAUDRATE\s\+.*/#define RK3399_BAUDRATE ${RK_CONSOLE_BAUD}/" ${S}/plat/rockchip/rk3399/rk3399_def.h
+}
+
+do_patch[postfuncs] += "fixup_rk3399_baudrate"
perhaps applying the sed expression via do_configure:prepend() is simple ?
and maybe make it rk3399 specific with do_configure:prepend:rk3399
It is effectively patching the sources, and I'd personally expect
sources to not be changed after running -c do_patch for a recipe.

That being said, I can have a:

fixup_baudrate() {
:
}

fixup_baudrate:rk3399() {
sed ....
}

do_patch[postfuncs] += "fixup_baudrate"

if you prefer. I have not tested but I assume this should work?
sounds good.


Cheers,
Quentin


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

Richard Purdie
 

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


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


Build hash information:

bitbake: f18b65d0b9a6b983d53bde491e1bf2ca56949444
meta-agl: 6d1ab9f3bb270a773ec5d2f7c8c856796833b559
meta-arm: ce535dfb96de4d2529f091d7d85a7172c626001c
meta-aws: 9979cfa676105cb68cfadfdaeabf044d7c919319
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: 87984115eb6ed1a4c17204629dcb100f6b76fe82
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
meta-openembedded: 69f94af4d91215e7d4e225bab54bf3bcfee42f1c
oecore: 90a07178ea26be453d101c2e8b33d3a0f437635d
poky: 795339092f87672e4f68e4d3bc4cfd0e252d1831



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


Yocto Technical Team Minutes, Engineering Sync, for December 7, 2021

Trevor Woerner
 

Yocto Technical Team Minutes, Engineering Sync, for December 7, 2021
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner, Stephen Jolley, Jasper Orschulko, Trevor Gamblin,
Steve Sakoman, Philip Balister, Richard Purdie, Randy MacLeod, Peter
Kjellerstedt, Jan-Simon Möller, Scott Murray, Alexandre Belloni, Tim
Orling, Jon Mason, Bruce Ashfield, Ross Burton, Joshua Watt, Michael
Opdenacker

== project status ==
- 3.5-m1 (kirkstone) to be built this week
- 3.4.1 (honister) out of QA and to be released
- changes to check-layer script leads to improvements to layer README files
- thanks to all for YPS last week
- continue to remove local patches by sending upstream
- rising intermittent issues with AB
- SWAT faltering, large backlog of un-triaged issues

== discussion ==
RP: Ross created graphs related to the changing number of patches and their
state (from 2015 to now) http://www.burtonini.com/yoctometrics/ The patch
status is clearly improving over time both in number and that they are
generally moving upstream. 5 years ago we peaked at 1900 patches, today
we’re at 1270-ish. It’s nice to note how much progress we can make
when we put our resources towards it. Sometimes looking at a patch shows
us that it is no longer required. Upstream is usually receptive, sometimes
it’s just a matter of poking again.

JPEW: i was working on meta-phosh and noticed that libsoup is all messed
up now. there are 2 versions (v2 and v3) and you’re not supposed to
mix-and-match. libsoup2 and 3 were both updated so that if they noticed
the other one, they both hard fail (they call abort() on the process to
kill it). previously things wouldn’t function correctly, now things
won’t run at all. biggest offender is webkitgtk was upgraded to use
libsoup3 but nothing else has been upgraded so anything links in webkitgtk
crashes on startup. there are a surprising number of things in gnome that
crash e.g. settings panel.
Ross: probably easiest to add a packageconfig on webkit so distro maintainers
get to pick
JPEW: it looks like most things will probably switch to libsoup3 when they
update to gtk4 (and won’t switch before then), but for now pretty much
everything in meta-gnome is completely broken. currently libsoup3 is not
used by anything other than webkitgtk
Ross: probably should make libsoup2 the default for now to regress the
breakage
RP: sounds reasonable to me

JPEW: at OEDVM we were talking about open-source projects getting Yocto
compliance. i was working on meta-phosh but not sure what to do next.
maybe next thing is to talk to the board?
RP: not the board, talk to Nico. Nico is the gatekeeper for the compatibility
process, and it goes to the TSC if required after. there are forms on the
website, but the website is iffy, so if you fill in the forms and nothing
happens, then reach out to Nico directly. it’s probably best to just
reach out to Nico directly.

RP: something that may be landing in the next few days, Ross is recommending
that we remove libtool prefix. libtool is prefixed with an architecture
prefix. this is something that OE and buildroot did early on and we’ve
been carrying this for decades. there was a time when it looked like
autoconf was going to mandate that build tools had the cross-compiler
triplet prepended, but autotools looks dead now-a-days. ironically libtool
rejected the patches
Ross: everything it was trying to solve is now solved with recipe-specific
sysroots, and host tools, etc. so everything should just work. any recipe
that has to hand-code libtool work-arounds can all be removed now. i
expect the fallout to be substantial, but the fixes will be to just remove
stuff from recipes. does buildroot still do this?
RP: not sure
Ross: i don’t see any patches for libtool at all (in buildroot)
RP: the cross-compile support in upstream libtool is broken; well, not broken
but inefficient. but, as Ross says, it is obsolete now.
Ross: lots of diffstat lines removed, but it will make the AB explode
AlexB: buildroot has patches for libtool, even multiple versions (see
support/libtool, not package/libtool)
Ross: ah, i was looking in the wrong place
RP: is supporting multiple versions of libtool not a path to madness?
supporting one version is bad enough…
Ross: it looks like it’s doing the same as our patches (i.e. fixing the
relink thing)
RP: yes, buildroot is patching for the the relink thing (which is something we
do as well) but the prefix patch isn’t in buildroot
Ross: i’ll clean this up and post it as an RFC at least
RP: sounds good

Ross: going back to the chart thing, there was talk a while ago about the LF
having a centralized git monitoring/metrics thing?
RP: LFX
Ross: ah yes! is it still going? can we add our stuff into it? it would be
nice to inject out patch data stuff there
RP: they are still doing it, and there are developers actively working on it,
but the people working on it have more pressing things to work on. so the
answer is yes, but not now. there are lots of stuff i’d like to do this
with, e.g. CVE metrics is another. it would be nice to find someone who
would be interested in generating dashboard data for the project from what
we’re producing. we have the ability to inject this stuff, we just need
to generate it
TimO: we need a data scientist

Jon: i sent out an email about inclusive language, please read and respond
RP: where?
Jon: main yocto, oe-devel, oe-core. trying to get the ball rolling to see if
it can land this release
MO: i’m interested, it ties in with documentation
RP: me too

RP: Quentin sent a patch to rename… core-image-master (?) to golden instead.
this is part of the QA test framework and was from a time when we had
ideas about test controllers etc. i checked with the QA team and they
aren’t using it. i did a double-take on that name, it’s not something
i’ve used recently and there haven’t been any patches for it in ages.
i had completely forgotten about its existence, despite being listed as
the maintainer! is anyone using this code?
JPEW: core-image-test-master
ScottM: i had never heard of it before
Ross: i almost ripped it out a few weeks back when i was doing a cleanup
of the QA code. there is someone who is either using that code, or a
derivative of it. i’ll copy them in on that thread so they can have an
opinion. but if it’s not being used then it can probably be deleted.
RP: rather than rename, i’m very tempted to just delete it. it’s not used
and likely broken. even if someone is using it, there are probably better
things they should be doing

RP: there’s another breaking change to one of the tunes that we should
probably fix before M1…
Jon: A72?
RP: yes, thanks. the crypto extension is enabled by default in the tune, but
there’s now an rpi4 that has an SoC that doesn’t enable it. there
are 2 ways to fix this: 1) leave the current tune as-is and create a
-nocrypto variant 2) change the current tune to remove the crypto, then
add a -crypto variant. not sure what path to take; i’m leaning towards
the latter since that fits in better with the rest of the framework even
if it is more disruptive. tune stuff is already complicated, i’d rather
we keep the framework consistent. i also would prefer a better commit
comment
Jon: should i respin their patch with the updated wording? or comment on it to
have them updated it?
RP: either way; preferred to have it before -m1
Jon: just to be clear, this won’t break anything, it’ll just make it
slightly less performant
RP: right, and i think that’s reasonable
ScottM: only meta-raspberrypi is affected by this?
Jon: meta-raspberrypi is broken by this
ScottM: oh right, after this change everyone else will have this off
Jon: right. meta-raspberrypi, meta-rockchip, and possibly a freescale layer
will be affected
JPEW: so just manually re-enable it?
Jon+RP: exactly
Jon: yes, change to cortex-a72 + crypto

RP: anyone using SH4? or anyone know of someone using it?
Randy: nobody we know of (WindRiver)
ScottM: nobody that I know of (AGL)
MO: it’s an SoC for settop boxes (?)
ScottM: maybe Khem would know
RP: Khem is the one who patched it in the past, but not sure if he’s doing
it because he’s using it (or knows someone using it) or if he’s just
doing it because he’s aware of the patches
RP: I came across this as part of the patch clean up exercise; there are some
SH4 patches we’re carrying for glibc. we need to decide if we’re going
to support this going forward. i’m under the impression that if someone
wanted to get SH4 working, they would need more than these glibc patches.
it would probably be better as an external architecture port/layer rather
than odd, random hacks in oe-core
ScottM: if Khem signs off on it then it sounds reasonable to me
RP: i’ll talk to Khem

Peter: i’ve noticed a problem with debug packages with honister. in june
there was a change to remove the attempt-only for complimentary packages,
so they are no longer called with skip-broken complimentary packages. this
hid issues in our packaging. in our case we use gstreamer plugins (bad
maybe) for srtp. the thing is we also have our own plugin for srtp. so
we build the gstreamer plugin for srtp both as part of the gstreamer-bad
package and from our own package. this works fine for the product images
(since each plugin is put in its own package) but the debug symbols are
all put in one package. meaning there is a clash for installing the debug
symbols for both gstreamer and our package. is there any support for
splitting the debug packages (similiar to how the main package is split),
or are debug packages expected to all be all in one package?
JPEW: are you asking if you can split? currently there is one debug package
per recipe
Peter: exactly. but because we are mixing plugins between 2 packages, the
debug symbols clash. i would like the debug packages split just like the
plugin packages are split. and i don’t know how the complimentary stuff
works; and how it knows, for each plugin, that it should pick up the
common debug package rather than the debug package that has the same name
as the plugin package
RP: it’s a good question. i’ve wondered about this in the past. yours
isn’t the only scenario where you can hit this problem. the downside
is the extra impact on the build. generating all these extra packages,
and putting these extra packages into the package feed, etc.. will have
an impact on the overall build and i’m not sure it will make anything
more usable. it would fix some things, but cause other things. i also
wouldn’t underestimate the amount of work involved to get this to work.
RP: the easier fix is to make the files non-overlapping (by renaming)
Peter: the problem is that our srtp is a drop-in replacement, so the plugins
(files) are called exactly the same (they have to be) so you get the same
file in both packages
RP: you could make it a symlink (the debug symbols will be based on the
original file, not the symlink), if you rename the file but made a symlink
that might get around the issue
Peter: interesting idea…
RP: we’ve moving the goal-posts, but i think the symlink path would be
easier
TrevorW: honister-specific?
Peter: yes, there was a change (june 28) in the package manager. previously,
the complimentary packages were built attempt-only=true so dnf was called
with the skip-broken option which ended up hiding the issue. it would
ignore installing one of the packages at random. so previously there was
a chance that symbols wouldn’t be there, and nobody would notice unless
they were specifically needing those symbols. the honister change is an
improvement since it makes it obvious when an issue comes up.
ScottM: it would be nice to have the debug packages setup the same way other
distros do, but if it blows up the build times, then that would probably
not be worth it. it would be nice if someone had the cycles to prototype
it so we’d have the data
RP: it’s probably optimizable to some extent. we have some crazy build times
for things like packaging ltp. for ltp it probably doesn’t matter, but
for perl-modules it probably does. if you add more packages the build time
scales badly. one of the implications would be separate debug symbols for
each kernel module, which would at least double the number of packages in
a kernel build
Peter: for us we’d just do it for gstreamer, since that’s the only one
causing us issues. in an ideal world everything would be handled the same
RP: you can do that and the system will let you do that, but that’s not
a change i’d take into core. currently the policy is to have 1 debug
package per recipe, and that’s not something we’re about to change.
separate debug packages will work, but will affect build times
Peter: i could just remove the debug symbols for one of the packages, and hope
nobody ever needs to debug it
RP: separate debug packages will work, but we’re not going to change the
policy
Peter: i also have a similar problem with hardknott (which still has the
keep-broken option enabled) so i can’t figure that out. similar, but not
the same

TrevorW: there was discussion around having more of a presentation +
discussion style meeting each month at the OE happy hour
Jon: possible, we have done it in the past, we’re open to it, but it’s
hard to get people to do it (and having them do the prep). but having
a YPS gives people something to shoot for. lots of work to do a
presentation, OEHH is more informal. it would need someone or something
to drive it and make it more formal. Paul Barker has done a couple
show-and-tells informally at some OEHHs
TimO: i like the spontaneous show-and-tell
Jon: most people are trained to think in terms of conferences and doing
presentations there. trying to do it informally might make it less likely
to happen. we can take it to the board

RP: i’ve been chatting with Khem and he says the SH4 patches are there
because i wanted them in, so i guess i’ll remove them


Re: Using FreeRadius project on Yocto

Khem Raj
 

On Tue, Dec 14, 2021 at 11:34 AM Rakesh Kumar <rakeshkumar0815@...> wrote:



Hi Team,


I am trying to build radius server with the use of Yocto project and looks like freeradius recipe is already included in meta-openembedded/meta-networking/recipes-connectivity/freeradius


I have included meta-openembedded layer in my conf/bblayers.conf file and built core-image-base image.


But I couldn't see anything related to radius server in my <workspace>/tmp directory


"tmp/work/ccimx6ul/core-image-base/1.0-r0/rootfs/etc/init.d"


Could you please let me know do I need to add anything specific to build radius server apart from using meta-openembedded recipe? I apologize if this is the wrong mailing list.
just adding layer is not enough, you have to add it to your image as well via
IMAGE_INSTALL or some other way as indirect dependency

Thanks much!


Best Regards

Rakesh kumar








Re: Yocto BUILD ENV

Monsees, Steven C (US)
 

 

So, I ran SDK build using “bitbake sbcb-defaults-full –k –c populate_sdk_ext”

 

Everthing builds under the SDK except 1 component … the intel-graphics-compiler-native/1.0.11-r0, which fails a few times for the header file reference shown below.

 

It also appears as though :

 

    /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/hosttools/g++ 

 

Is pointer to the correct devtoolset-8 version

 

I feel as though I am missing something with regards to the EXT SDK env, but not sure what,,,

 

I have tried adding the “source /opt/rh/devtoolset-8/enable” to /etc/bashrc, /etc/profile, and have tried running “scl enable devtoolset-8 bash” prior to build… (all of which work correctly building the standard SDK, and my kernel image which are building in the IGC…

 

Sample error output:

 

| [63/565] /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/hosttools/g++  -DCL_KHR_FP64_EXT -DGHAL3D=USC -DICBE_LINUX -DIGC_CMAKE -DIGC_EXPORTS=1 -DIGC_SPIRV_ENABLED -DINSIDE_PLUGIN -DISTDLIB_UMD -DLINUX -DNDEBUG -DNOMINMAX -DSTD_CALL -DUSC_EXPORTS=1 -DUSE_MMX -DUSE_SSE -DUSE_SSE2 -DUSE_SSE3 -DUSE_SSSE3 -D_AMD64_ -D_COMPILER_DLL_ -D_CRT_SECURE_NO_WARNINGS -D_HAS_EXCEPTIONS=0 -D_IGC_ -D_SCL_SECURE_NO_WARNINGS -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/WrapperLLVM/include -IIGC/autogen -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/.. -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../Common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../3d/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common/Compiler -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common/Compiler/API -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../visa/include -IIGC/Release -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/AdaptorOCL/ocl_igc_shared/executable_format -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/AdaptorOCL -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common/Compiler/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/AdaptorOCL/cif/cif/.. -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler -isystem/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/recipe-sysroot-native/usr/include -pipe -fno-exceptions -fdata-sections -ffunction-sections -O2 -fmessage-length=0 -march=corei7 -mstackrealign -fms-extensions -Werror -Wno-unused-parameter -Wno-missing-field-initializers -Wwrite-strings -Wno-long-long -Wswitch -Wno-sign-compare -Wno-unused-result -Wno-enum-compare -Wno-type-limits -Wno-ignored-qualifiers -Wformat -Wformat-security -Wno-extra -Wno-write-strings -finline -fno-strict-aliasing -msse -msse2 -msse3 -mssse3 -msse4 -msse4.1 -msse4.2 -Wno-unknown-pragmas -fPIC -D_FORTIFY_SOURCE=2 -fstack-protector -finline-functions -funswitch-loops -Wno-maybe-uninitialized -lrt -fno-rtti -fvisibility=hidden -fvisibility-inlines-hidden -std=c++14 -DNDEBUG -g   -std=gnu++14 -MD -MT IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/CShader.cpp.o -MF IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/CShader.cpp.o.d -o IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/CShader.cpp.o -c /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/CShader.cpp

| FAILED: IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/CShader.cpp.o

| /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/hosttools/g++  -DCL_KHR_FP64_EXT -DGHAL3D=USC -DICBE_LINUX -DIGC_CMAKE -DIGC_EXPORTS=1 -DIGC_SPIRV_ENABLED -DINSIDE_PLUGIN -DISTDLIB_UMD -DLINUX -DNDEBUG -DNOMINMAX -DSTD_CALL -DUSC_EXPORTS=1 -DUSE_MMX -DUSE_SSE -DUSE_SSE2 -DUSE_SSE3 -DUSE_SSSE3 -D_AMD64_ -D_COMPILER_DLL_ -D_CRT_SECURE_NO_WARNINGS -D_HAS_EXCEPTIONS=0 -D_IGC_ -D_SCL_SECURE_NO_WARNINGS -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/WrapperLLVM/include -IIGC/autogen -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/.. -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../Common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../3d/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common/Compiler -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common/Compiler/API -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../visa/include -IIGC/Release -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/AdaptorOCL/ocl_igc_shared/executable_format -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/AdaptorOCL -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../inc/common/Compiler/common -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/AdaptorOCL/cif/cif/.. -I/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler -isystem/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/recipe-sysroot-native/usr/include -pipe -fno-exceptions -fdata-sections -ffunction-sections -O2 -fmessage-length=0 -march=corei7 -mstackrealign -fms-extensions -Werror -Wno-unused-parameter -Wno-missing-field-initializers -Wwrite-strings -Wno-long-long -Wswitch -Wno-sign-compare -Wno-unused-result -Wno-enum-compare -Wno-type-limits -Wno-ignored-qualifiers -Wformat -Wformat-security -Wno-extra -Wno-write-strings -finline -fno-strict-aliasing -msse -msse2 -msse3 -mssse3 -msse4 -msse4.1 -msse4.2 -Wno-unknown-pragmas -fPIC -D_FORTIFY_SOURCE=2 -fstack-protector -finline-functions -funswitch-loops -Wno-maybe-uninitialized -lrt -fno-rtti -fvisibility=hidden -fvisibility-inlines-hidden -std=c++14 -DNDEBUG -g   -std=gnu++14 -MD -MT IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/CShader.cpp.o -MF IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/CShader.cpp.o.d -o IGC/Compiler/CMakeFiles/Compiler.dir/CISACodeGen/CShader.cpp.o -c /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/CShader.cpp

| In file included from /usr/include/sys/stat.h:106,

|                  from /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/../3d/common/iStdLib/File.h:47,

|                  from /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/DebugInfo.hpp:42,

|                  from /disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-default/tmp/work/x86_64-linux/intel-graphics-compiler-native/1.0.11-r0/git/IGC/Compiler/CISACodeGen/CShader.cpp:44:

| /usr/include/bits/stat.h:106:31: error: expected unqualified-id before ‘[’ token

|      __syscall_slong_t __unused[3];

|                                ^

| /usr/include/bits/stat.h:164:31: error: expected unqualified-id before ‘[’ token

|      __syscall_slong_t __unused[3];

|                                ^

 

 

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Tuesday, December 14, 2021 2:23 PM
To: yocto@...
Subject: [yocto] Yocto BUILD ENV

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

 

I am using a pre-installed tools on my linux development box for centos7, that being devtoolset-8…

 

Running “source /opt/rh/devtoolset-8/enable” allows me to build my bootapp, kernel, and the standard SDK without issues…, but there seems to be a problem when I go to build the extended SDK.

 

It appears to end up referencing the wrong/default tool set.

 

Is the something I need to set in my sdk-extra.conf (or one of the vcarious other configuration files)  to make the extended SDK build aware of the environment dependency ?

 

 

/opt/rh/devtoolset-8/enable script does the following:

 

# General environment variables

export PATH=/opt/rh/devtoolset-8/root/usr/bin${PATH:+:${PATH}}

export MANPATH=/opt/rh/devtoolset-8/root/usr/share/man:${MANPATH}

export INFOPATH=/opt/rh/devtoolset-8/root/usr/share/info${INFOPATH:+:${INFOPATH}}

export PCP_DIR=/opt/rh/devtoolset-8/root

# Some perl Ext::MakeMaker versions install things under /usr/lib/perl5

# even though the system otherwise would go to /usr/lib64/perl5.

export PERL5LIB=/opt/rh/devtoolset-8/root//usr/lib64/perl5/vendor_perl:/opt/rh/devtoolset-8/root/usr/lib/perl5:/opt/rh/devtoolset-8/root//usr/share/perl5/vendor_perl${PERL5LIB:+:${PERL5LIB}}

# bz847911 workaround:

# we need to evaluate rpm's installed run-time % { _libdir }, not rpmbuild time

# or else /etc/ld.so.conf.d files?

rpmlibdir=$(rpm --eval "%{_libdir}")

# bz1017604: On 64-bit hosts, we should include also the 32-bit library path.

if [ "$rpmlibdir" != "${rpmlibdir/lib64/}" ]; then

  rpmlibdir32=":/opt/rh/devtoolset-8/root${rpmlibdir/lib64/lib}"

fi

export LD_LIBRARY_PATH=/opt/rh/devtoolset-8/root$rpmlibdir$rpmlibdir32${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}

export LD_LIBRARY_PATH=/opt/rh/devtoolset-8/root$rpmlibdir$rpmlibdir32:/opt/rh/devtoolset-8/root$rpmlibdir/dyninst$rpmlibdir32/dyninst${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}

# duplicate python site.py logic for sitepackages

pythonvers=2.7

export PYTHONPATH=/opt/rh/devtoolset-8/root/usr/lib64/python$pythonvers/site-packages:/opt/rh/devtoolset-8/root/usr/lib/python$pythonvers/site-packages${PYTHONPATH:+:${PYTHONPATH}}

export PKG_CONFIG_PATH=/opt/rh/devtoolset-8/root/usr/lib64/pkgconfig${PKG_CONFIG_PATH:+:${PKG_CONFIG_PATH}}

 


Using FreeRadius project on Yocto

Rakesh Kumar <rakeshkumar0815@...>
 



Hi Team,


I am trying to build radius server with the use of Yocto project and looks like freeradius recipe is already included in meta-openembedded/meta-networking/recipes-connectivity/freeradius 


I have included meta-openembedded layer in my conf/bblayers.conf file and built core-image-base image.


But I couldn't see anything related to radius server in my <workspace>/tmp directory 


"tmp/work/ccimx6ul/core-image-base/1.0-r0/rootfs/etc/init.d"


Could you please let me know do I need to add anything specific to build radius server apart from using meta-openembedded recipe? I apologize if this is the wrong mailing list.


Thanks much!


Best Regards

Rakesh kumar






Yocto BUILD ENV

Monsees, Steven C (US)
 

 

I am using a pre-installed tools on my linux development box for centos7, that being devtoolset-8…

 

Running “source /opt/rh/devtoolset-8/enable” allows me to build my bootapp, kernel, and the standard SDK without issues…, but there seems to be a problem when I go to build the extended SDK.

 

It appears to end up referencing the wrong/default tool set.

 

Is the something I need to set in my sdk-extra.conf (or one of the vcarious other configuration files)  to make the extended SDK build aware of the environment dependency ?

 

 

/opt/rh/devtoolset-8/enable script does the following:

 

# General environment variables

export PATH=/opt/rh/devtoolset-8/root/usr/bin${PATH:+:${PATH}}

export MANPATH=/opt/rh/devtoolset-8/root/usr/share/man:${MANPATH}

export INFOPATH=/opt/rh/devtoolset-8/root/usr/share/info${INFOPATH:+:${INFOPATH}}

export PCP_DIR=/opt/rh/devtoolset-8/root

# Some perl Ext::MakeMaker versions install things under /usr/lib/perl5

# even though the system otherwise would go to /usr/lib64/perl5.

export PERL5LIB=/opt/rh/devtoolset-8/root//usr/lib64/perl5/vendor_perl:/opt/rh/devtoolset-8/root/usr/lib/perl5:/opt/rh/devtoolset-8/root//usr/share/perl5/vendor_perl${PERL5LIB:+:${PERL5LIB}}

# bz847911 workaround:

# we need to evaluate rpm's installed run-time % { _libdir }, not rpmbuild time

# or else /etc/ld.so.conf.d files?

rpmlibdir=$(rpm --eval "%{_libdir}")

# bz1017604: On 64-bit hosts, we should include also the 32-bit library path.

if [ "$rpmlibdir" != "${rpmlibdir/lib64/}" ]; then

  rpmlibdir32=":/opt/rh/devtoolset-8/root${rpmlibdir/lib64/lib}"

fi

export LD_LIBRARY_PATH=/opt/rh/devtoolset-8/root$rpmlibdir$rpmlibdir32${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}

export LD_LIBRARY_PATH=/opt/rh/devtoolset-8/root$rpmlibdir$rpmlibdir32:/opt/rh/devtoolset-8/root$rpmlibdir/dyninst$rpmlibdir32/dyninst${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}

# duplicate python site.py logic for sitepackages

pythonvers=2.7

export PYTHONPATH=/opt/rh/devtoolset-8/root/usr/lib64/python$pythonvers/site-packages:/opt/rh/devtoolset-8/root/usr/lib/python$pythonvers/site-packages${PYTHONPATH:+:${PYTHONPATH}}

export PKG_CONFIG_PATH=/opt/rh/devtoolset-8/root/usr/lib64/pkgconfig${PKG_CONFIG_PATH:+:${PKG_CONFIG_PATH}}

 


Re: [meta-rockchip] [PATCH v2] trusted-firmware-a: replace baudrate with the one specified in machine conf

Khem Raj
 

On Tue, Dec 14, 2021 at 3:39 AM Quentin Schulz
<quentin.schulz@...> wrote:

Not all Rockchip boards have their console running at 1500000 baud in
U-Boot and the kernel. Such is the case for puma-haikou RK3399-based
SoM+Carrierboard.

In order to prepare for the addition of puma-haikou to meta-rockchip,
let's replace the baudrate in TF-A by the one defined in the machine
conf file in the RK_CONSOLE_BAUD variable.

Cc: Quentin Schulz <foss+yocto@...>
Signed-off-by: Quentin Schulz <quentin.schulz@...>
---

v2: use a less restrictive regular expression

.../files/serial-console-baudrate.patch | 36 -------------------
.../trusted-firmware-a_%.bbappend | 6 +++-
2 files changed, 5 insertions(+), 37 deletions(-)
delete mode 100644 recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch

diff --git a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
deleted file mode 100644
index 2d6e9bf..0000000
--- a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-From 840d6b6420e1fd8cdf6e4de7fa58a6f8de151622 Mon Sep 17 00:00:00 2001
-From: Yann Dirson <yann@...>
-Date: Tue, 6 Apr 2021 17:28:45 +0200
-Subject: [PATCH] Set serial console baudrate back to 1500000.
-Upstream-Status: Inappropriate[other]
-
-TF-A runs between two u-boot stages which both uses 1500000 baud, it
-just makes no sense to use the same UART at a different rate.
-
-This effectively reverts part of 0c05748bdebfad9fa43a80962186438bb8fbce62.
-Main reason for that change stated in https://developer.trustedfirmware.org/T762
-is ChromeOS compatibility.
-
-Looks like this patch may become unnecessary in the future, when
-u-boot and TF-A get to communicate this value.
-
----
- plat/rockchip/rk3399/rk3399_def.h | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h
-index ba83242eb..8d6ecfbe6 100644
---- a/plat/rockchip/rk3399/rk3399_def.h
-+++ b/plat/rockchip/rk3399/rk3399_def.h
-@@ -17,7 +17,7 @@
- /**************************************************************************
- * UART related constants
- **************************************************************************/
--#define RK3399_BAUDRATE 115200
-+#define RK3399_BAUDRATE 1500000
- #define RK3399_UART_CLOCK 24000000
-
- /******************************************************************************
---
-2.30.2
-
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index 513cea1..07fae1e 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -7,7 +7,6 @@ COMPATIBLE_MACHINE:append:rk3328 = "|rk3328"

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
SRC_URI += "\
- file://serial-console-baudrate.patch \
file://0001-dram-Fix-build-with-gcc-11.patch \
file://0001-plat_macros.S-Use-compatible-.asciz-asm-directive.patch \
file://0001-pmu-Do-not-mark-already-defined-functions-as-weak.patch \
@@ -19,3 +18,8 @@ SRC_URI += "\
# this needs fixing until then use gcc
TOOLCHAIN:rk3399 = "gcc"

+fixup_rk3399_baudrate() {
+ sed -i "s/#define RK3399_BAUDRATE\s\+.*/#define RK3399_BAUDRATE ${RK_CONSOLE_BAUD}/" ${S}/plat/rockchip/rk3399/rk3399_def.h
+}
+
+do_patch[postfuncs] += "fixup_rk3399_baudrate"
perhaps applying the sed expression via do_configure:prepend() is simple ?
and maybe make it rk3399 specific with do_configure:prepend:rk3399

--
2.33.1




Yocto Project Status WW50`21

Stephen Jolley
 

Current Dev Position: YP 3.5 M1

Next Deadline: 6th Dec. 2021 YP 3.5 M1 build

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.5 M1 is in QA
  • YP 3.1.13 is due to build this week
  • We have maintenance to the autobuilder planned to fit SSDs to speed up IO and update the host distros to more modern equivalents. If parts arrive as planned, this is scheduled for next week (20th-24th) and the autobuilder will be unavailable during the work. There may be bring up issues with the new distros.
  • There were significant improvements in patch metrics this week with large drops in both patches in the pending state and overlap number of patches. Thanks to everyone who contributed to that!
  • As part of patch cleanup, some changes were made which could impact other layers or our spectrum of support. The libtool prefix patches were dropped as the need was largely obsolete by recipe specific sysroots, hosttools and other developments and this may mean patches in other layers can be dropped too. Some non-upstream invasive mips and sh4 patches were dropped as they were either obsolete or there were less invasive ways to handle them. 
  • CVE metrics improved this week with drops in open CVEs for both dunfull and master.
  • Intermittent issues continue to rise and help is very much welcome on these 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

 

Ways to contribute:

 

YP 3.5 Milestone Dates:

  • YP 3.5 M1 in QA
  • YP 3.5 M1 Release date 2021/12/17
  • YP 3.5 M2 build date 2022/01/10
  • YP 3.5 M2 Release date 2022/1/21
  • YP 3.5 M3 build date 2022/2/21
  • YP 3.5 M3 Release date 2022/03/04
  • YP 3.5 M4 build date 2022/04/04
  • YP 3.5 M4 Release date 2022/04/29

 

Upcoming dot releases:

  • YP 3.4.1  is released
  • YP 3.1.13 build date 2021/12/13
  • YP 3.1.13 Release date 2021/12/22
  • YP 3.1.14 build date 2022/01/24
  • YP 3.1.14 Release date 2022/02/04
  • YP 3.4.2 build date 2022/02/07
  • YP 3.4.2 Release date 2022/02/18
  • YP 3.3.5 build date 2022/02/14
  • YP 3.3.5 Release date 2022/02/25
  • YP 3.1.15 build date 2022/03/14
  • YP 3.1.15 Release date 2022/03/25
  • YP 3.4.3 build date 2022/03/21
  • YP 3.4.3 Release date 2022/04/01
  • YP 3.3.6 build date 2022/03/28
  • YP 3.3.6 Release date 2022/04/08
  • YP 3.1.16 build date 2022/04/25
  • YP 3.1.16 Release date 2022/05/06

 

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: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.5_M1.rc2)

Teoh, Jay Shen
 

Hi everyone,

Intel and WR YP QA is planning for QA execution for YP build yocto-3.5_M1.rc2. 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 this Friday, 17th of December.

Thanks,
Jay

-----Original Message-----
From: qa-build-notification@... <qa-build-
notification@...> On Behalf Of Richard Purdie
Sent: Sunday, 12 December, 2021 6:49 PM
To: <yocto@...> <yocto@...>
Cc: qa-build-notification <qa-build-notification@...>
Subject: [qa-build-notification] QA notification for completed autobuilder build
(yocto-3.5_M1.rc2)

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


https://autobuilder.yocto.io/pub/releases/yocto-3.5_M1.rc2


Build hash information:

bitbake: 1ecc1d9424877df89fcda2f23c306998998a65ff
meta-agl: 6d1ab9f3bb270a773ec5d2f7c8c856796833b559
meta-arm: d446f7f80bf61e9cf05843e8ef4bc5473f936118
meta-aws: 8893e0cd4c0981eeda941eaa9ad2eb9359670502
meta-gplv2: f04e4369bf9dd3385165281b9fa2ed1043b0e400
meta-intel: aa8482af7b286f8fe8f7aae648938d4ebf0283c5
meta-mingw: 992fb40bdbfe9fe60f815aac46e04c58963918b5
meta-openembedded: ba6a16cdca661b2d5251df243dc19bda0e8db651
oecore: 1a6c2a7345199d77ad5aeac8ad337ed80a8aa39b
poky: 65c94ca3196e5ef3344a469fea8e30444f2e967a



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







Re: echo and read shell script functions in post install script doesn't display messages

Alexander Kanavin
 

The postinst scriptlets are script fragments and not standalone scripts. Putting an interpreter to their first line will not work. Also, they are not running on an interactive console, but by a helper executor, so they have to be entirely automated.

What is the problem that you would like to solve?

Alex


On Tue, 14 Dec 2021 at 13:01, <sanjaycvr35412@...> wrote:

Hi All,

 

I am trying to execute a script in “pkg_postinst_ontarget_${PN}” to configure the static IP address of the embedded board. The script executes at first boot, but it doesn’t display echo or read messages. These messages are required to improve user experience with the setup process.

 

Script is as below:

pkg_postinst_ontarget_${PN} () {

    #!/bin/sh -e

    # This will run on first boot

    echo "Starting setup script..."

 

    read -p "Enter the IP address: " ipAddress

    read -p "Enter the netmask: " netmask

    read -p "Enter network gateway: " gateway

 

    cat >> /etc/network/interfaces << EOF

 

iface eth0 inet static

    address $ipAddress

    netmask $netmask

    gateway $gateway

EOF

}

 

Please help me to fix the problem in displaying echo and read messages to improve user experience with the setup process.

 

Thanks,

Sanjay Kumar

 




1781 - 1800 of 57338