[yocto] QA notification for completed autobuilder build (yocto-3.1.11.rc2)
A build flagged for QA (yocto-3.1.11.rc2) was completed on the autobuilder and is available at: https://autobuilder.yocto.io/pub/releases/yocto-3.1.11.rc2 Build hash information: bitbake: c2a3bda3a29e12472ef7862e424ea1552fab2959 meta-agl: 60344efa7a50dc2548fc4b5d68b5ad4d60c4023a meta-arm: ce535dfb96de4d2529f091d7d85a7172c626001c meta-aws: c5164c1a795c21f7caccc3b68bb2e81a55bddb0e meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac meta-intel: 6837552365d3cac5f8044a5ae910aa874435f766 meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7 meta-openembedded: 2e7e98cd0cb82db214b13224c71134b9335a719b oecore: c7d2281eb6cda9c1637c20b3540b142073bca235 poky: 74b22db6879b388d700f61e08cb3f239cf940d18 This is an automated message from the Yocto Project Autobuilder Git: git://git.yoctoproject.org/yocto-autobuilder2 Email: richard.pur...@linuxfoundation.org -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54736): https://lists.yoctoproject.org/g/yocto/message/54736 Mute This Topic: https://lists.yoctoproject.org/mt/85646188/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] QA notification for completed autobuilder build (yocto-3.1.11.rc1)
A build flagged for QA (yocto-3.1.11.rc1) was completed on the autobuilder and is available at: https://autobuilder.yocto.io/pub/releases/yocto-3.1.11.rc1 Build hash information: bitbake: c2a3bda3a29e12472ef7862e424ea1552fab2959 meta-agl: 60344efa7a50dc2548fc4b5d68b5ad4d60c4023a meta-arm: ce535dfb96de4d2529f091d7d85a7172c626001c meta-aws: c5164c1a795c21f7caccc3b68bb2e81a55bddb0e meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac meta-intel: 6837552365d3cac5f8044a5ae910aa874435f766 meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7 meta-openembedded: 5c347d8ce425dcb4896e6f873810b8bfff5e4e92 oecore: 49ca1f62cc17c951b7737a4ee3c236f732bc8ebe poky: 80b8fc829f809ce07809a89a00cec3ee9dc18795 This is an automated message from the Yocto Project Autobuilder Git: git://git.yoctoproject.org/yocto-autobuilder2 Email: richard.pur...@linuxfoundation.org -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54729): https://lists.yoctoproject.org/g/yocto/message/54729 Mute This Topic: https://lists.yoctoproject.org/mt/85633027/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [yocto-autobuilder2][PATCH] add prioritizeBuilders
On Sat, 2021-09-11 at 14:07 +0100, Richard Purdie via lists.yoctoproject.org
wrote:
> On Thu, 2021-09-09 at 09:10 -0400, Trevor Gamblin wrote:
> > This prioritizeBuilders function sorts builders by the length of their
> > associated worker lists, so that builders that can only be assigned to a
> > small number of workers are assigned to those workers before other
> > builds that don't have specific needs when resources are limited. An
> > example might be when a slot is available on an Ubuntu-based worker, and
> > "oe-selftest-ubuntu" and "genericx86-64" build requests exist in the
> > queue. Since oe-selftest-ubuntu requires an Ubuntu-based worker and
> > genericx86-64 does not, genericx86-64 will be assigned a higher value
> > (lower priority) so that oe-selftest-ubuntu is assigned to that worker
> > first.
> >
> > Signed-off-by: Trevor Gamblin
> > ---
> > builders.py | 13 +
> > master.cfg | 6 ++
> > 2 files changed, 19 insertions(+)
> >
>
> We did merge and start using this. Unfortunately whilst I thought it would
> work,
> it has some unfortunate side effects and we'll probably have to disable it.
>
> If you have two build requests for say "a-full" builds, it will allocate oe-
> selftest-XXX and reproducible-XXX to the XXX workers, starving generic
> targets.
> You therefore end up with two builds running, both with half their builder
> targets and it will hurt completion.
>
> I did talk with upstream buildbot a little on irc about this challenge.
>
> The default prioritizeBuilders function (_defaultSorter in
> buildrequestdistributor.py) sorts by build request time.
>
> They were suggesting some things which are fairly invasive like adding a
> estimated completion time to the defaultSorter so we could weight slow builds.
> To be honest it's beyond my comfort level with twisted defereds trying to
> query
> and obtain the right data.
>
> I have started wondering if we can in fact cheat and tweak the order we
> trigger
> the builds in the a-full and a-quick targets. I think we could influence the
> order of builderNames in the Triggerable and that would then change the
> buildrequest timestamps so the default sorting method would work better for us
> again.
>
> I think that translates to adding your sorting method in this patch to
> builderNamesFromConfigQuick and builderNamesFromConfigFull. Probably worth a
> try?
Upstream gave this as an example which I think we can probably do something
with:
from datetime import datetime, timedelta
from dateutil.tz import tzutc
from twisted.internet import defer
# this stores bonuses for builders, which takes in account longer build time
builder_bonuses = {
'bldr1': timedelta(hours=1)
}
def BuilderSorter(master, builders):
# perform an asynchronous schwarzian transform, transforming None
# into a really big date, so that any
# date set to 'None' will appear at the
# end of the list during comparisons.
max_time = datetime.max
# Need to set the timezone on the date, in order
# to perform comparisons with other dates which
# have the time zone set.
max_time = max_time.replace(tzinfo=tzutc())
@defer.inlineCallbacks
def transform(bldr):
time = yield bldr.getOldestRequestTime()
if time is None:
time = max_time
else:
if bldr.name in builder_bonuses:
time = time + builder_bonuses[bldr.name]
defer.returnValue((time, bldr))
transformed = yield defer.gatherResults(
[transform(bldr) for bldr in builders])
# sort the transformed list synchronously, comparing None to the end of
# the list
def transformedKey(a):
(date, builder) = a
return (date, builder.name)
transformed.sort(key=transformedKey)
# and reverse the transform
rv = [xf[1] for xf in transformed]
return rv
c['prioritizeBuilders'] = BuilderSorter
and then we're not relying on internal bebehaviours with the sorting. It was
pointed out to me that the timestamps are only second accuracy so the global
builders list sorting would probably have more effect.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54703): https://lists.yoctoproject.org/g/yocto/message/54703
Mute This Topic: https://lists.yoctoproject.org/mt/85483506/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [yocto-autobuilder2][PATCH] add prioritizeBuilders
On Thu, 2021-09-09 at 09:10 -0400, Trevor Gamblin wrote: > This prioritizeBuilders function sorts builders by the length of their > associated worker lists, so that builders that can only be assigned to a > small number of workers are assigned to those workers before other > builds that don't have specific needs when resources are limited. An > example might be when a slot is available on an Ubuntu-based worker, and > "oe-selftest-ubuntu" and "genericx86-64" build requests exist in the > queue. Since oe-selftest-ubuntu requires an Ubuntu-based worker and > genericx86-64 does not, genericx86-64 will be assigned a higher value > (lower priority) so that oe-selftest-ubuntu is assigned to that worker > first. > > Signed-off-by: Trevor Gamblin > --- > builders.py | 13 + > master.cfg | 6 ++ > 2 files changed, 19 insertions(+) > We did merge and start using this. Unfortunately whilst I thought it would work, it has some unfortunate side effects and we'll probably have to disable it. If you have two build requests for say "a-full" builds, it will allocate oe- selftest-XXX and reproducible-XXX to the XXX workers, starving generic targets. You therefore end up with two builds running, both with half their builder targets and it will hurt completion. I did talk with upstream buildbot a little on irc about this challenge. The default prioritizeBuilders function (_defaultSorter in buildrequestdistributor.py) sorts by build request time. They were suggesting some things which are fairly invasive like adding a estimated completion time to the defaultSorter so we could weight slow builds. To be honest it's beyond my comfort level with twisted defereds trying to query and obtain the right data. I have started wondering if we can in fact cheat and tweak the order we trigger the builds in the a-full and a-quick targets. I think we could influence the order of builderNames in the Triggerable and that would then change the buildrequest timestamps so the default sorting method would work better for us again. I think that translates to adding your sorting method in this patch to builderNamesFromConfigQuick and builderNamesFromConfigFull. Probably worth a try? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54702): https://lists.yoctoproject.org/g/yocto/message/54702 Mute This Topic: https://lists.yoctoproject.org/mt/85483506/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Sharing sstate cache across build nodes
On Fri, 2021-09-10 at 11:16 -0600, Rusty Howell wrote: > We are having a problem with the PR server resetting the PR number it is > returning for a given package/arch/checksum. Our setup is as follows: We > have multiple linux servers being used as build nodes. Each node can build any > one of four MACHINE types that we have defined in our distro. These builds > actually happen inside a docker container on the build nodes. We have a > global PR server running on a separate server. > > Each node has it's own SSTATE_DIR, DL_DIR, and all bitbake builds on a node > will use the same SSTATE_DIR, DL_DIR. Those directories are shared with the > docker containers. > > Our distro has many recipes that have a git SRC_URI with a branch name as the > rev. So they need to use AUTOINC. > What we are noticing is that once in a while, the revs being served out by the > PR server will be reset back to 0, and thus break upgrade-ability with the > debian packages. > > I have been unable to find much information about how to properly configure > multiple build nodes so that they all have consistent PR values from the PR > server. > > I know there are several directories that might be necessary to achieve my > goal. > PERSISTENT_DIR, SSTATE_DIR, BUILDHISTORY_DIR, DL_DIR > > Can someone help explain which dirs should/must be shared via NFS/smb across > all build nodes? Which directories are node-specific and only need to be > cached locally (but not NFS) and used for all local build jobs? Does changing > the MACHINE type on the build affect how/if these directories can be shared? In general you need the sstate and the PR server to match. Using multiple different pools of sstate with the same PR server will probably not work so well. It won't matter about DL_DIR or PERSISTENT_DIR. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54701): https://lists.yoctoproject.org/g/yocto/message/54701 Mute This Topic: https://lists.yoctoproject.org/mt/85515144/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] QA notification for completed autobuilder build (yocto-3.3.3.rc2)
A build flagged for QA (yocto-3.3.3.rc2) was completed on the autobuilder and is available at: https://autobuilder.yocto.io/pub/releases/yocto-3.3.3.rc2 Build hash information: bitbake: c7b506d11df78cfc4610db6578745eaa6220b13a meta-agl: 60344efa7a50dc2548fc4b5d68b5ad4d60c4023a meta-arm: ba82ea920a3a43244a0a72bd74817e2f00f4a1af meta-aws: 171aa2cf4d12ff4877e9104b6ec46be54128e3d8 meta-gplv2: 9e119f333cc8f53bd3cf64326f826dbc6ce3db0f meta-intel: 5c4a6b02f650a99a5ec55561443fcf880a863d19 meta-mingw: 422b96cb2b6116442be1f40dfb5bd77447d1219e meta-openembedded: 7bd7e1da9034e72ca4262dba55f70b2b23499aae oecore: 567dd35d893c5d8969d41f263a24da8fbae3fc2f poky: 0a2ca9d60f3851515a79d5aa9ddd8b4069b5a206 This is an automated message from the Yocto Project Autobuilder Git: git://git.yoctoproject.org/yocto-autobuilder2 Email: richard.pur...@linuxfoundation.org -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54691): https://lists.yoctoproject.org/g/yocto/message/54691 Mute This Topic: https://lists.yoctoproject.org/mt/85493706/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [poky] Poky:dunfell: SDK install issue (sed: -e expression #1, char 0: no previous regular expression)
On Tue, 2021-09-07 at 06:10 +, Groeting, Claus wrote: > Hi all! > > I have a problem with this commit, applied in poky:dunfell on file toolchain- > shar-relocate.sh. > sha1: d6f40be29bf56a835f5825692a22365f04aeb6c3 > > Author: hongxu 2021-08-10 15:33:56 > Committer: Richard Purdie 2021-08-26 > 09:32:18 > Parent: dad6dd12fd6e2512f3bd5591327ee35ee22b913e (toolchain-shar-relocate.sh: > Fix handling files with colons) > Branches: dunfell, remotes/origin/dunfell > Follows: dunfell-23.0.10, yocto-3.1.10 > Precedes: > > sdk: fix relocate symlink failed > > > (From OE-Core rev: a155c4d4ca841ef492213a5f0b9121703c62e2b4) > > Signed-off-by: Hongxu Jia > Signed-off-by: Alexandre Belloni > Signed-off-by: Richard Purdie > (cherry picked from commit 942c06a7348070b92f722fa5c439c8c4404485b7) > Signed-off-by: Steve Sakoman > Signed-off-by: Richard Purdie > > meta/files/toolchain-shar-relocate.sh > > index 5433741296..ba873373e2 100644 > @@ -72,7 +72,7 @@ fi > > # change all symlinks pointing to @SDKPATH@ > for l in $($SUDO_EXEC find $native_sysroot -type l); do > - $SUDO_EXEC ln -sfn $(readlink $l|$SUDO_EXEC sed -e > "s:$DEFAULT_INSTALL_DIR:$target_sdk_dir:") $l > + $SUDO_EXEC ln -sfn $(readlink $l|$SUDO_EXEC sed -e > "s:$SDK_BUILD_PATH:$target_sdk_dir:") $l > if [ $? -ne 0 ]; then > echo "Failed to setup symlinks. Relocate script failed. Abort!" > exit 1 > > it looks to me that SDK_BUILD_PATH is not defined in the sed instruction. When > installing the generated SDK shell script, we see a lot of: > sed: -e expression #1, char 0: no previous regular expression > sed: -e expression #1, char 0: no previous regular expression > sed: -e expression #1, char 0: no previous regular expression > sed: -e expression #1, char 0: no previous regular expression > sed: -e expression #1, char 0: no previous regular expression > sed: -e expression #1, char 0: no previous regular expression > > Without that commit, everything looks ok. On master-branch SDK_BUILD_PATH is > preset with "@SDKPATH@" but not on dunfell-branch this is missing in the > file toolchain-shar-relocate.sh. Hi, I think there is a patch queued in the testing branch for dunfell: http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=stable/dunfell-nut http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=stable/dunfell-nut&id=ed0f6236ceb6a127903241f783a526bcdefc66ce that should address this. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54672): https://lists.yoctoproject.org/g/yocto/message/54672 Mute This Topic: https://lists.yoctoproject.org/mt/85446004/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [PATCH v2] bitbake/fetch2: Add a new variable 'BB_FETCH_ENV' to export Fetcher env
Hi,
Thanks for the patch. This isn't ready to be merged yet though as there are some
issues.
On Mon, 2021-08-23 at 15:18 +0800, jiladahe1...@gmail.com wrote:
> From 1b0d7b4bb4a5b39f7ae0ce7d7ae5897a33637972 Mon Sep 17 00:00:00 2001
> From: Mingrui Ren
> Date: Mon, 23 Aug 2021 14:49:03 +0800
> Subject: [PATCH v2] bitbake/fetch2: Add a new variable 'BB_FETCH_ENV' to
> export Fetcher env
>
> The environment variables used by Fetcher are hard-coded, and are obtained
> from HOST env instead of bitbake datastore
This isn't true, they are looked at first in bitbake's datastore, then taken
from the original host environment if not in the datastore.
> This patch add a new variable 'BB_FETCH_ENV',and modify the default
> BB_ENV_EXTRAWHITE_OE for backwards compatibility, trying to fix the
> problems above.
Why is this a problem? You need to state what the problem is, not what the code
currently does (or in the above case doesn't do).
> Signed-off-by: Mingrui Ren
> ---
> changes in v2:
> a.changes the variable name from 'FETCH_ENV_WHITELIST' to 'BB_FETCH_ENV'.
> b.add 'BB_FETCH_ENV' in local.conf, rather than export it in host
>enviroment.
> c.modify existing BB_ENV_EXTRAWHITE_OE for backwards compatibility.
> d.Two commits recently modified this variable. The commit ID is:
>348384135272ae7c62a11eeabcc43eddc957811f and
> 5dce2f3da20a14c0eb5229696561b0c5f6fce54c,
>So I adjusted the new variables in the patch.
>
> bitbake/lib/bb/fetch2/__init__.py | 34 ---
> bitbake/lib/bb/fetch2/wget.py | 2 +-
> meta-poky/conf/local.conf.sample | 12 +++
> scripts/oe-buildenv-internal | 3 ++-
> 4 files changed, 24 insertions(+), 27 deletions(-)
>
> diff --git a/bitbake/lib/bb/fetch2/__init__.py
> b/bitbake/lib/bb/fetch2/__init__.py
> index 914fa5c024..cbbe32d1df 100644
> --- a/bitbake/lib/bb/fetch2/__init__.py
> +++ b/bitbake/lib/bb/fetch2/__init__.py
> @@ -808,28 +808,13 @@ def localpath(url, d):
> fetcher = bb.fetch2.Fetch([url], d)
> return fetcher.localpath(url)
>
> -# Need to export PATH as binary could be in metadata paths
> -# rather than host provided
> -# Also include some other variables.
> -FETCH_EXPORT_VARS = ['HOME', 'PATH',
> - 'HTTP_PROXY', 'http_proxy',
> - 'HTTPS_PROXY', 'https_proxy',
> - 'FTP_PROXY', 'ftp_proxy',
> - 'FTPS_PROXY', 'ftps_proxy',
> - 'NO_PROXY', 'no_proxy',
> - 'ALL_PROXY', 'all_proxy',
> - 'GIT_PROXY_COMMAND',
> - 'GIT_SSH',
> - 'GIT_SSL_CAINFO',
> - 'GIT_SMART_HTTP',
> - 'SSH_AUTH_SOCK', 'SSH_AGENT_PID',
> - 'SOCKS5_USER', 'SOCKS5_PASSWD',
> - 'DBUS_SESSION_BUS_ADDRESS',
> - 'P4CONFIG',
> - 'SSL_CERT_FILE',
> - 'AWS_ACCESS_KEY_ID',
> - 'AWS_SECRET_ACCESS_KEY',
> - 'AWS_DEFAULT_REGION']
Firstly, I'd prefer not to move this list out of the fetcher code. Bitbake can
be in theory used standalone without the OE-Core metadata and this data makes
more sense to be maintained in the fetcher.
> +def getfetchenv(d):
> +# Need to export PATH as binary could be in metadata paths
> +# rather than host provided
> +# Also include some other variables.
> +vars = ['HOME', 'PATH']
> +vars.extend((d.getVar("BB_FETCH_ENV") or "").split())
> +return vars
>
> def runfetchcmd(cmd, d, quiet=False, cleanup=None, log=None, workdir=None):
> """
> @@ -839,7 +824,7 @@ def runfetchcmd(cmd, d, quiet=False, cleanup=None,
> log=None, workdir=None):
> Optionally remove the files/directories listed in cleanup upon failure
> """
>
> -exportvars = FETCH_EXPORT_VARS
> +exportvars = getfetchenv(d)
>
> if not cleanup:
> cleanup = []
> @@ -855,9 +840,8 @@ def runfetchcmd(cmd, d, quiet=False, cleanup=None,
> log=None, workdir=None):
> d.setVar("PV", "fetcheravoidrecurse")
> d.setVar("PR", "fetcheravoidrecurse")
>
> -origenv = d.getVar("BB_ORIGENV", False)
> for var in exportvars:
> -val = d.getVar(var) or (origenv and origenv.getVar(var))
> +val = d.getVar(var)
> if val:
> cmd = 'export ' + var + '=\"%s\"; %s' % (val, cmd)
>
Please don't drop the BB_ORIGENV handling. Why is that being removed?
>
> diff --git a/bitbake/lib/bb/fetch2/wget.py b/bitbake/lib/bb/fetch2/wget.py
> index 29fcfbb3d1..0ce06ddb4f 100644
> --- a/bitbake/lib/bb/fetch2/wget.py
> +++ b/bitbake/lib/bb/fetch2/wget.py
> @@ -306,7 +306,7 @@ class Wget(FetchMethod):
> # to scope the changes to the build_opener request, which is when the
> # environment lookups happen.
> newenv = {}
> -for name in bb.fetch2.FETCH_EXPORT_VARS:
> +
[yocto] QA notification for completed autobuilder build (yocto-3.3.3.rc1)
A build flagged for QA (yocto-3.3.3.rc1) was completed on the autobuilder and is available at: https://autobuilder.yocto.io/pub/releases/yocto-3.3.3.rc1 Build hash information: bitbake: 9b2d96b27f550da0fa68ba9ea96be98eb3a832a6 meta-agl: 60344efa7a50dc2548fc4b5d68b5ad4d60c4023a meta-arm: ba82ea920a3a43244a0a72bd74817e2f00f4a1af meta-aws: 171aa2cf4d12ff4877e9104b6ec46be54128e3d8 meta-gplv2: 9e119f333cc8f53bd3cf64326f826dbc6ce3db0f meta-intel: 5c4a6b02f650a99a5ec55561443fcf880a863d19 meta-mingw: 422b96cb2b6116442be1f40dfb5bd77447d1219e meta-openembedded: 5741b949a875b07335d4920aefa6defd13ed45c6 oecore: e3a7eaf9fe1420b2525e14f0c0f2936e7818b8a3 poky: 4624b855ed47c5da08953191bfbb39e764ecb343 This is an automated message from the Yocto Project Autobuilder Git: git://git.yoctoproject.org/yocto-autobuilder2 Email: richard.pur...@linuxfoundation.org -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54648): https://lists.yoctoproject.org/g/yocto/message/54648 Mute This Topic: https://lists.yoctoproject.org/mt/85372998/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] QA notification for completed autobuilder build (yocto-3.4_M3.rc1)
A build flagged for QA (yocto-3.4_M3.rc1) was completed on the autobuilder and is available at: https://autobuilder.yocto.io/pub/releases/yocto-3.4_M3.rc1 Build hash information: bitbake: 0a11696e0898c3c5108e6d7c5ad28da50e00ea66 meta-agl: 60344efa7a50dc2548fc4b5d68b5ad4d60c4023a meta-arm: 46e8fc6a67efbcc357cf507b903a3e3e133c78f7 meta-aws: 32ae20566a39454ab0ba4c80c23a32ed7c14dcaf meta-gplv2: f04e4369bf9dd3385165281b9fa2ed1043b0e400 meta-intel: cb1bf2bdc1b20f76fde8b291a12b361a4bc2511e meta-mingw: f5d761cbd5c957e4405c5d40b0c236d263c916a8 meta-openembedded: 1511e25cea69b98bf2778984d7a649dad5597878 oecore: ffb886497390d4de2631bda671f2f631bc0bc7be poky: f2728d3ec8c0589e02e9a3ce7cf8aca902cae0a3 This is an automated message from the Yocto Project Autobuilder Git: git://git.yoctoproject.org/yocto-autobuilder2 Email: richard.pur...@linuxfoundation.org -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54647): https://lists.yoctoproject.org/g/yocto/message/54647 Mute This Topic: https://lists.yoctoproject.org/mt/85372990/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [meta-mingw] [PATCH] grpc: remove nl2 requirement since it is optional
On Fri, 2021-08-20 at 20:46 +, Sinan Kaya wrote: > Signed-off-by: Sinan Kaya > --- > .../openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git > a/dynamic-layers/openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend > b/dynamic-layers/openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend > index a72496d..dc0ea42 100644 > --- a/dynamic-layers/openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend > +++ b/dynamic-layers/openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend > @@ -1,2 +1,5 @@ > +# doesn't build and not required > +DEPENDS:remove:mingw32 = "libnsl2" > + > EXTRA_OECMAKE:remove:mingw32 = "-DBUILD_SHARED_LIBS=ON" > EXTRA_OECMAKE:append:mingw32 = " -DBUILD_SHARED_LIBS=OFF" Should we be making that a PACKAGECONFIG which mingw32 could change? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54527): https://lists.yoctoproject.org/g/yocto/message/54527 Mute This Topic: https://lists.yoctoproject.org/mt/85030549/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-gplv2] [PATCH 1/2] layer.conf: Set elfutils version correctly
We need to set PREFERRED_VERSION for elfutils or the wrong one will be used.
Signed-off-by: Richard Purdie
---
conf/layer.conf | 1 +
1 file changed, 1 insertion(+)
diff --git a/conf/layer.conf b/conf/layer.conf
index 3abe6b5..b0915d4 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -18,5 +18,6 @@ LAYERSERIES_COMPAT_gplv2 = "honister"
LICENSE_PATH += "${LAYERDIR}/licenses"
+PREFERRED_VERSION_elfutils = "${@['', '0.148']['GPLV3' in
(d.getVar('INCOMPATIBLE_LICENSE') or '').upper()]}"
PREFERRED_VERSION_shared-mime-info = "${@['', '1.10']['GPLV3' in
(d.getVar('INCOMPATIBLE_LICENSE') or '').upper()]}"
PREFERRED_VERSION_shared-mime-info-native = "${@['', '1.10']['GPLV3' in
(d.getVar('INCOMPATIBLE_LICENSE') or '').upper()]}"
--
2.32.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54517): https://lists.yoctoproject.org/g/yocto/message/54517
Mute This Topic: https://lists.yoctoproject.org/mt/85001599/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-gplv2] [PATCH 2/2] elfutils: Work around reproducibility issue
The version in this layer doesn't reproduce, so disable the warnings/errors and allow it to build. Signed-off-by: Richard Purdie --- recipes-devtools/elfutils/elfutils_0.148.bb | 3 +++ 1 file changed, 3 insertions(+) diff --git a/recipes-devtools/elfutils/elfutils_0.148.bb b/recipes-devtools/elfutils/elfutils_0.148.bb index 848e2cf..97d88a2 100644 --- a/recipes-devtools/elfutils/elfutils_0.148.bb +++ b/recipes-devtools/elfutils/elfutils_0.148.bb @@ -66,6 +66,9 @@ CFLAGS += "-Wno-error=format-truncation=" # but 0.182 has different license, so to be safe don't backport the fix, just ignore the issue CFLAGS += "-Wno-error=stringop-overflow=" +# There are fixes in later versions for this but the old version won't be reproducible +TARGET_CC_ARCH:remove:class-target = " -Wdate-time" + EXTRA_OECONF = "--program-prefix=eu- --without-lzma" EXTRA_OECONF:append:class-native = " --without-bzlib" -- 2.32.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54516): https://lists.yoctoproject.org/g/yocto/message/54516 Mute This Topic: https://lists.yoctoproject.org/mt/85001598/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Weird bitbake generation behavior
On Wed, 2021-08-18 at 06:23 +, Frans Meulenbroeks via
lists.yoctoproject.org wrote:
> Hi,
>
> I share an sstate-cache with my fellow developers and I was assessing why
> sometimes things got rebuild even
> though I did not expect this.
> One of the things I discovered was that we had two versions of of
> glog/0.3.5-r0 in sstate.
> The difference was caused run.do_configure where one user had this in
> run.do_configure
>
> do_configure() {
> cmake_do_configure
> # remove WORKDIR info to improve reproducibility
> if [ -f
> "/workdir/build-nano/tmp/work/aarch64-sorama-linux/glog/0.3.5-r0/build/config.h"
> ] ; then
> sed -i 's/'$(echo
> /workdir/build-nano/tmp/work/aarch64-sorama-linux/glog/0.3.5-r0 | sed
> 's_/_\\/_g')'/../g'
> /workdir/build-nano/tmp/work/aarch64-sorama-linux/glog/0.3.5-r0/build/config.h
> fi
> }
>
> whereas the other just had:
>
> do_configure() {
> cmake_do_configure
> }
>
>
> The weird thing is that these two builds were about a day apart, they were
> build on the same system with as
> far as I know the same metadata, the same distro, the same image etc etc
> User settings should also be the same (we build under docker and I checked,
> we used the same version of ubuntu
> in the container (18.04). (Actually the containers were generated from the
> same Docker file and docker inspect
> tells me the images are identical).
>
> Anyone an idea how this happens and where that extra snippet comes from? (I
> grepped for the string
> "reproducibility" in the bitbake folder, but that did not help)
> BTW we're using dunfell
Google shows:
https://patchwork.openembedded.org/patch/176924/
so I'd check the glog recipe.
https://git.openembedded.org/meta-openembedded/commit/?id=be95549f2ea5c59c6da6ace852b918cdba3c7822
https://git.openembedded.org/meta-openembedded/commit/?h=dunfell&id=a51c0d9b3a0d7dc5986ce46e7de65ef26cd06373
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54473): https://lists.yoctoproject.org/g/yocto/message/54473
Mute This Topic: https://lists.yoctoproject.org/mt/84968574/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] New Override Syntax
On Wed, 2021-08-11 at 10:18 +0200, Michael Opdenacker wrote: > Hi Richard, > > On 8/10/21 10:21 PM, Richard Purdie wrote: > > On Tue, 2021-08-10 at 17:51 +, Darcy Watkins wrote: > > > My apologies. I don't think I made my question clear. I am asking about > > > the > > > compatibility of old style override syntax moving forward (and new style > > > syntax > > > in old versions). > > > > > > So if I continue using the old style override syntax (to ensure sure > > > compatibility for use with older Yocto versions), at what future Yocto/OE > > > release do you expect that old style override syntax will become > > > erroneous > > > (as opposed to say triggering deprecation warnings, etc)? > > > > > > Is support for the new style override syntax present in any existing > > > Yocto/OpenEmbedded releases (in other words, has it been there for a > > > while, > > > but we are just now actively migrating to use it)? If so, how far back > > > does it go? > > The new syntax will work on the dunfell, gatesgarth, hardknott, master and > > new > > release branches going forward. That applies now and that support will be > > in the > > next point releases for dunfell (3.1.11) and hardknott (3.3.3). > > > Thank you for the clarification. > > Why do you mention Gatesgarth (3.2) while no update release is in sight? > According to https://wiki.yoctoproject.org/wiki/Releases, it's already > end of life. I mention is as if I didn't someone would ask about it. I did backport the change to the corresponding bitbake branch and it hence made it to the poky branch for gatesgarth but there are no plans for any further 3.2 releases. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54369): https://lists.yoctoproject.org/g/yocto/message/54369 Mute This Topic: https://lists.yoctoproject.org/mt/84796653/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] New Override Syntax
On Tue, 2021-08-10 at 17:51 +, Darcy Watkins wrote: > My apologies. I don't think I made my question clear. I am asking about the > compatibility of old style override syntax moving forward (and new style > syntax > in old versions). > > So if I continue using the old style override syntax (to ensure sure > compatibility for use with older Yocto versions), at what future Yocto/OE > release do you expect that old style override syntax will become erroneous > (as opposed to say triggering deprecation warnings, etc)? > > Is support for the new style override syntax present in any existing > Yocto/OpenEmbedded releases (in other words, has it been there for a while, > but we are just now actively migrating to use it)? If so, how far back does > it go? The new syntax will work on the dunfell, gatesgarth, hardknott, master and new release branches going forward. That applies now and that support will be in the next point releases for dunfell (3.1.11) and hardknott (3.3.3). The old syntax is no longer supported in master as of now and will not be supported in new releases going forward. It continues to work fine in older releases prior to the next new release series (honister). Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54364): https://lists.yoctoproject.org/g/yocto/message/54364 Mute This Topic: https://lists.yoctoproject.org/mt/84796653/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-gplv2] [PATCH 2/3] meta-gplv2: Convert to new override syntax
This converts the layer to the new override syntax. This was done using
/scripts/contrib/convert-overrides.py
with no manual fixes.
Signed-off-by: Richard Purdie
---
conf/distro/include/disable-gplv3.inc | 4 +--
recipes-bsp/grub/grub_0.97.bb | 4 +--
recipes-core/coreutils/coreutils_6.9.bb | 2 +-
recipes-core/gettext/gettext_0.16.1.bb| 28 +--
recipes-core/readline/readline_5.2.bb | 4 +--
recipes-devtools/bison/bison_2.3.bb | 2 +-
recipes-devtools/elfutils/elfutils_0.148.bb | 24
recipes-devtools/m4/m4-1.4.9.inc | 2 +-
recipes-devtools/mtools/mtools_3.9.9.bb | 6 ++--
recipes-devtools/patch/patch.inc | 2 +-
recipes-devtools/rsync/rsync.inc | 2 +-
recipes-extended/bash/bash.inc| 22 +++
recipes-extended/bc/bc_1.06.bb| 2 +-
recipes-extended/cpio/cpio_v2.inc | 6 ++--
recipes-extended/diffutils/diffutils.inc | 2 +-
recipes-extended/diffutils/diffutils_2.8.1.bb | 2 +-
recipes-extended/ed/ed_0.5.bb | 6 ++--
recipes-extended/findutils/findutils.inc | 2 +-
recipes-extended/gawk/gawk_3.1.5.bb | 14 +-
recipes-extended/gperf/gperf.inc | 2 +-
recipes-extended/grep/grep_2.5.1a.bb | 6 ++--
recipes-extended/groff/groff_1.18.1.4.bb | 4 +--
recipes-extended/gzip/gzip.inc| 8 +++---
recipes-extended/libidn/libidn_0.6.14.bb | 4 +--
recipes-extended/mc/mc_4.7.5.2.bb | 18 ++--
recipes-extended/msmtp/msmtp_1.4.12.bb| 4 +--
recipes-extended/sed/sed_4.1.2.bb | 4 +--
recipes-extended/tar/tar.inc | 14 +-
recipes-extended/texinfo/texinfo_4.8.bb | 18 ++--
recipes-extended/time/time_1.7.bb | 2 +-
recipes-extended/which/which_2.18.bb | 4 +--
recipes-sato/rxvt-unicode/rxvt-unicode.inc| 12
recipes-support/gdbm/gdbm_1.8.3.bb| 2 +-
recipes-support/gmp/gmp.inc | 4 +--
recipes-support/gmp/gmp_4.2.1.bb | 2 +-
recipes-support/gnupg/gnupg_1.4.7.bb | 8 +++---
recipes-support/gnutls/gnutls.inc | 20 ++---
recipes-support/libiconv/libiconv_1.11.1.bb | 6 ++--
recipes-support/nettle/nettle.inc | 2 +-
recipes-support/nettle/nettle_2.7.1.bb| 2 +-
.../shared-mime-info/shared-mime-info.inc | 10 +++
41 files changed, 146 insertions(+), 146 deletions(-)
diff --git a/conf/distro/include/disable-gplv3.inc
b/conf/distro/include/disable-gplv3.inc
index bded378..5d948cc 100644
--- a/conf/distro/include/disable-gplv3.inc
+++ b/conf/distro/include/disable-gplv3.inc
@@ -1,3 +1,3 @@
INCOMPATIBLE_LICENSE = '*GPLv3*'
-WARN_QA_remove = 'incompatible-license'
-RDEPENDS_${PN}-ptest_remove_pn-glib-2.0 = "python3-dbusmock"
+WARN_QA:remove = 'incompatible-license'
+RDEPENDS:${PN}-ptest:remove:pn-glib-2.0 = "python3-dbusmock"
diff --git a/recipes-bsp/grub/grub_0.97.bb b/recipes-bsp/grub/grub_0.97.bb
index 3e4e12c..3845c94 100644
--- a/recipes-bsp/grub/grub_0.97.bb
+++ b/recipes-bsp/grub/grub_0.97.bb
@@ -9,7 +9,7 @@ LICENSE = "GPLv2+"
LIC_FILES_CHKSUM = "file://COPYING;md5=c93c0550bd3173f4504b2cbd8991e50b \
file://grub/main.c;beginline=3;endline=9;md5=22a5f28d2130fff9f2a17ed54be90ed6"
-RDEPENDS_${PN} = "diffutils"
+RDEPENDS:${PN} = "diffutils"
PR = "r6"
SRC_URI = "http://alpha.gnu.org/gnu/grub/grub-${PV}.tar.gz; \
@@ -29,7 +29,7 @@ COMPATIBLE_HOST = "i.86.*-linux"
EXTRA_OECONF = "--without-curses"
-do_install_append_vmware() {
+do_install:append_vmware() {
mkdir -p ${D}/boot/
ln -sf ../usr/lib/grub/{$TARGET_ARCH}{$TARGET_VENDOR}/ ${D}/boot/grub
}
diff --git a/recipes-core/coreutils/coreutils_6.9.bb
b/recipes-core/coreutils/coreutils_6.9.bb
index 69e5489..8f24556 100644
--- a/recipes-core/coreutils/coreutils_6.9.bb
+++ b/recipes-core/coreutils/coreutils_6.9.bb
@@ -92,7 +92,7 @@ inherit update-alternatives
ALTERNATIVE_PRIORITY = "100"
-ALTERNATIVE_${PN} = "lbracket ${bindir_progs} ${base_bindir_progs}
${sbindir_progs}"
+ALTERNATIVE:${PN} = "lbracket ${bindir_progs} ${base_bindir_progs}
${sbindir_progs}"
ALTERNATIVE_PRIORITY[uptime] = "10"
ALTERNATIVE_PRIORITY[hostname] = "10"
diff --git a/recipes-core/gettext/gettext_0.16.1.bb
b/recipes-core/gettext/gettext_0.16.1.bb
index 1907ea5..76c2a01 100644
--- a/recipes-core/gettext/gettext_0.16.1.bb
+++ b/recipes-core/gettext/gettext_0.16.1.bb
@@ -7,9 +7,9 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=9ea3144f04c41cd2eada5d3f472e6ea5"
PR = "r6"
DEPENDS = "virtual/libiconv"
-DEPENDS_class-native = "
[yocto] [meta-gplv2] [PATCH 3/3] layer.conf: Update to honister
This marks the layers as compatible with honister now they use the new override
syntax.
Signed-off-by: Richard Purdie
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/conf/layer.conf b/conf/layer.conf
index 9fc797a..3abe6b5 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -14,7 +14,7 @@ LAYERVERSION_gplv2 = "1"
LAYERDEPENDS_gplv2 = "core"
-LAYERSERIES_COMPAT_gplv2 = "hardknott"
+LAYERSERIES_COMPAT_gplv2 = "honister"
LICENSE_PATH += "${LAYERDIR}/licenses"
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54263): https://lists.yoctoproject.org/g/yocto/message/54263
Mute This Topic: https://lists.yoctoproject.org/mt/84539964/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-gplv2] [PATCH 1/3] recipes: Drop libc-uclibc overrides and patch
These haven't been used for a long time and can therefore be removed.
Signed-off-by: Richard Purdie
---
recipes-core/gettext/gettext_0.16.1.bb| 8 --
.../uclibc-support-for-elfutils-0.148.patch | 91 ---
recipes-devtools/elfutils/elfutils_0.148.bb | 9 +-
recipes-devtools/m4/m4.inc| 1 -
recipes-devtools/mtools/mtools_3.9.9.bb | 2 -
recipes-extended/findutils/findutils.inc | 7 --
recipes-support/gnutls/gnutls.inc | 1 -
7 files changed, 2 insertions(+), 117 deletions(-)
delete mode 100644
recipes-devtools/elfutils/elfutils-0.148/uclibc-support-for-elfutils-0.148.patch
diff --git a/recipes-core/gettext/gettext_0.16.1.bb
b/recipes-core/gettext/gettext_0.16.1.bb
index dacdfd3..1907ea5 100644
--- a/recipes-core/gettext/gettext_0.16.1.bb
+++ b/recipes-core/gettext/gettext_0.16.1.bb
@@ -27,8 +27,6 @@ SRC_URI[sha256sum] =
"0bf850d1a079fb5a61f0a47b1a9efd35eb44032255375e1cedb0253bc2
PARALLEL_MAKE = ""
-LDFLAGS_prepend_libc-uclibc = " -lrt -lpthread "
-
inherit autotools texinfo
EXTRA_OECONF += "--without-lispdir \
@@ -81,15 +79,9 @@ FILES_gettext-runtime = "${bindir}/gettext \
${libdir}/libasprintf${SODEV} \
${libdir}/GNU.Gettext.dll \
"
-FILES_gettext-runtime_append_libc-uclibc = " ${libdir}/libintl.so.* \
- ${libdir}/charset.alias \
- "
FILES_gettext-runtime-staticdev += "${libdir}/libasprintf.a"
FILES_gettext-runtime-dev += "${includedir}/autosprintf.h \
${libdir}/libasprintf${SOLIBDEV}"
-FILES_gettext-runtime-dev_append_libc-uclibc = " ${libdir}/libintl.so \
- ${includedir}/libintl.h \
- "
FILES_gettext-runtime-doc = "${mandir}/man1/gettext.* \
${mandir}/man1/ngettext.* \
${mandir}/man1/envsubst.* \
diff --git
a/recipes-devtools/elfutils/elfutils-0.148/uclibc-support-for-elfutils-0.148.patch
b/recipes-devtools/elfutils/elfutils-0.148/uclibc-support-for-elfutils-0.148.patch
deleted file mode 100644
index 3cf16ac..000
---
a/recipes-devtools/elfutils/elfutils-0.148/uclibc-support-for-elfutils-0.148.patch
+++ /dev/null
@@ -1,91 +0,0 @@
-on uclibc systems libintl and libuargp are separate from libc.
-so they need to be specified on commandline when we use proxy-libintl
-then libintl is a static archive so it should be listed last since
-elfutils does not respect disable-nls we need to link in libintl
-
-We add a new option --enable-uclibc which will be used to control
-the uclibc specific configurations during build.
-
-Signed-off-by: Khem Raj
-
-Upstream-Status: Inappropriate [uclibc specific]
-
-Index: elfutils-0.148/configure.ac
-===
elfutils-0.148.orig/configure.ac
-+++ elfutils-0.148/configure.ac
-@@ -55,9 +55,16 @@ AS_IF([test "$use_locks" = yes], [AC_DEF
-
- AH_TEMPLATE([USE_LOCKS], [Defined if libraries should be thread-safe.])
-
-+AC_ARG_ENABLE([uclibc],
-+AS_HELP_STRING([--enable-uclibc], [Use uclibc for system libraries]),
-+use_uclibc=yes, use_uclibc=no)
-+AM_CONDITIONAL(USE_UCLIBC, test "$use_uclibc" = yes)
-+AS_IF([test "$use_uclibc" = yes], [AC_DEFINE(USE_UCLIBC)])
-+
-+AH_TEMPLATE([USE_UCLIBC], [Defined if uclibc libraries are used.])
-+
- dnl Add all the languages for which translations are available.
- ALL_LINGUAS=
--
- AC_PROG_CC
- AC_PROG_RANLIB
- AC_PROG_YACC
-Index: elfutils-0.148/libelf/Makefile.am
-===
elfutils-0.148.orig/libelf/Makefile.am
-+++ elfutils-0.148/libelf/Makefile.am
-@@ -93,7 +93,12 @@ if !MUDFLAP
- libelf_pic_a_SOURCES =
- am_libelf_pic_a_OBJECTS = $(libelf_a_SOURCES:.c=.os)
-
-+
- libelf_so_LDLIBS =
-+if USE_UCLIBC
-+libelf_so_LDLIBS += -lintl -luargp
-+endif
-+
- if USE_LOCKS
- libelf_so_LDLIBS += -lpthread
- endif
-Index: elfutils-0.148/libdw/Makefile.am
-===
elfutils-0.148.orig/libdw/Makefile.am
-+++ elfutils-0.148/libdw/Makefile.am
-@@ -98,6 +98,11 @@ if !MUDFLAP
- libdw_pic_a_SOURCES =
- am_libdw_pic_a_OBJECTS = $(libdw_a_SOURCES:.c=.os)
-
-+libdw_so_LDLIBS =
-+if USE_UCLIBC
-+libdw_so_LDLIBS += -lintl -luargp
-+endif
-+
- libdw_so_SOURCES =
- libdw.so: $(srcdir)/libdw.map libdw_pic.a \
- ../libdwfl/libdwfl_pic.a ../libebl/libebl.a \
-@@ -108,7 +113,7 @@ libdw.so: $(srcdir)/libdw.map libdw_pic.
- -Wl,--enable-new-dtags,-rpath,$(pkglibdir) \
- -Wl,--version-script,$<,--no-undefined \
- -Wl,--whole-archive $(filter-out $<,$^) -Wl,--no-whole-arc
[yocto] [meta-mingw] [PATCH 3/3] layer.conf: Mark the layer as compatible with honister
Signed-off-by: Richard Purdie --- conf/layer.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/conf/layer.conf b/conf/layer.conf index 194a55d..5fefa73 100644 --- a/conf/layer.conf +++ b/conf/layer.conf @@ -10,4 +10,4 @@ BBFILE_PRIORITY_meta-mingw = "8" LAYERDEPENDS_meta-mingw = "core" -LAYERSERIES_COMPAT_meta-mingw = "hardknott" \ No newline at end of file +LAYERSERIES_COMPAT_meta-mingw = "honister" \ No newline at end of file -- 2.30.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54261): https://lists.yoctoproject.org/g/yocto/message/54261 Mute This Topic: https://lists.yoctoproject.org/mt/84539747/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-mingw] [PATCH 2/3] meta-mingw: Override syntax conversion manual fixes
Fix a coupld of mis-converted lines from the automated override
conversion script.
Signed-off-by: Richard Purdie
---
recipes-devtools/gcc/gcc-runtime_%.bbappend | 4 ++--
recipes-graphics/wayland/wayland_%.bbappend | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/recipes-devtools/gcc/gcc-runtime_%.bbappend
b/recipes-devtools/gcc/gcc-runtime_%.bbappend
index 0013e88..1511abb 100644
--- a/recipes-devtools/gcc/gcc-runtime_%.bbappend
+++ b/recipes-devtools/gcc/gcc-runtime_%.bbappend
@@ -1,5 +1,5 @@
-FILES:libstdc++_append_mingw32 = " ${bindir}/libstdc++*.dll"
-FILES:libstdc++-staticdev_append_mingw32 = " ${libdir}/libstdc++.dll.a*"
+FILES:libstdc++:append:mingw32 = " ${bindir}/libstdc++*.dll"
+FILES:libstdc++-staticdev:append:mingw32 = " ${libdir}/libstdc++.dll.a*"
FILES:libssp:append:mingw32 = " ${bindir}/libssp*.dll"
# FILES:libgomp:append:mingw32 = " ${bindir}/libgomp*.dll"
diff --git a/recipes-graphics/wayland/wayland_%.bbappend
b/recipes-graphics/wayland/wayland_%.bbappend
index 86a9061..e8ca57d 100644
--- a/recipes-graphics/wayland/wayland_%.bbappend
+++ b/recipes-graphics/wayland/wayland_%.bbappend
@@ -1,6 +1,6 @@
# The assembly file that encodes the DTD string into wayland-scanner is not
# compatible with i686 MinGW
-PACKAGECONFIG:remove:mingw32_i686 = "dtd-validation"
+PACKAGECONFIG:remove:mingw32:i686 = "dtd-validation"
EXTRA_OECONF:class-nativesdk:mingw32 = "--disable-documentation
--disable-libraries"
EXTRA_OEMESON:class-nativesdk:mingw32 = "-Ddocumentation=false
-Dlibraries=false"
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54259): https://lists.yoctoproject.org/g/yocto/message/54259
Mute This Topic: https://lists.yoctoproject.org/mt/84539745/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-mingw] [PATCH 1/3] meta-mingw: Convert to new override syntax
This converts the two layers to the new override syntax. This was done using
/scripts/contrib/convert-overrides.py
Signed-off-by: Richard Purdie
---
classes/toolchain-scripts-mingw32.bbclass | 8 +++---
conf/machine-sdk/include/mingw32-common.inc | 26 +--
recipes-core/dbus/dbus_%.bbappend | 6 ++---
recipes-core/dtc/dtc_%.bbappend | 8 +++---
recipes-core/expat/expat_%.bbappend | 2 +-
recipes-core/gettext/gettext_%.bbappend | 14 +-
recipes-core/glib-2.0/glib-2.0_%.bbappend | 10 +++
recipes-core/libxml/libxml2_%.bbappend| 2 +-
recipes-core/meta/meta-environment.bbappend | 2 +-
.../nativesdk-packagegroup-sdk-host.bbappend | 2 +-
recipes-core/zlib/zlib_1.2.%.bbappend | 2 +-
.../binutils-cross-canadian_2.%.bbappend | 8 +++---
recipes-devtools/cmake/cmake_%.bbappend | 4 +--
.../gcc/gcc-cross-canadian_%.bbappend | 12 -
recipes-devtools/gcc/gcc-crosssdk_%.bbappend | 4 +--
recipes-devtools/gcc/gcc-runtime_%.bbappend | 16 ++--
recipes-devtools/gcc/gcc_%.bbappend | 4 +--
recipes-devtools/gcc/libgcc_%.bbappend| 8 +++---
.../gdb/gdb-cross-canadian_%.bbappend | 14 +-
recipes-devtools/go/go_%.bbappend | 4 +--
.../libtool/nativesdk-libtool_2.4.6.bbappend | 2 +-
.../nativesdk-mingw-w64-headers_8.0.0.bb | 4 +--
.../nativesdk-mingw-w64-runtime_8.0.0.bb | 6 ++---
.../nativesdk-mingw-w64-winpthreads_8.0.0.bb | 2 +-
recipes-devtools/ninja/ninja_%.bbappend | 4 +--
recipes-devtools/swig/swig_%.bbappend | 4 +--
.../diffutils/diffutils_%.bbappend| 6 ++---
.../libarchive/libarchive_%.bbappend | 2 +-
recipes-extended/libidn/libidn2_%.bbappend| 2 +-
recipes-extended/zstd/zstd_%.bbappend | 4 +--
recipes-graphics/libsdl2/libsdl2_%.bbappend | 4 +--
recipes-graphics/wayland/wayland_%.bbappend | 6 ++---
recipes-support/curl/curl_%.bbappend | 4 +--
.../libgcrypt/libgcrypt_%.bbappend| 6 ++---
.../libgpg-error/libgpg-error_%.bbappend | 2 +-
recipes-support/libiconv/libiconv_1.15.bb | 6 ++---
recipes-support/libmpc/libmpc_%.bbappend | 2 +-
recipes-support/libpcre/libpcre_%.bbappend| 8 +++---
recipes-support/mpfr/mpfr_4.1.%.bbappend | 2 +-
39 files changed, 116 insertions(+), 116 deletions(-)
diff --git a/classes/toolchain-scripts-mingw32.bbclass
b/classes/toolchain-scripts-mingw32.bbclass
index 0afbf7d..d96cb40 100644
--- a/classes/toolchain-scripts-mingw32.bbclass
+++ b/classes/toolchain-scripts-mingw32.bbclass
@@ -1,5 +1,5 @@
# Based off of the oe-core meta/classes/toolchain-scripts.bbclass version
-toolchain_create_sdk_env_script_sdkmingw32 () {
+toolchain_create_sdk_env_script:sdkmingw32 () {
# Create environment setup script
sdkpathnative=${7:-${SDKPATHNATIVE}}
prefix=${6:-${prefix_nativesdk}}
@@ -54,7 +54,7 @@ toolchain_create_sdk_env_script_sdkmingw32 () {
mv $script.new $script
}
-toolchain_shared_env_script_sdkmingw32 () {
+toolchain_shared_env_script:sdkmingw32 () {
echo 'set CC=${TARGET_PREFIX}gcc ${TARGET_CC_ARCH}
--sysroot=%SDKTARGETSYSROOT%' >> $script
echo 'set CXX=${TARGET_PREFIX}g++ ${TARGET_CC_ARCH}
--sysroot=%SDKTARGETSYSROOT%' >> $script
echo 'set CPP=${TARGET_PREFIX}gcc -E ${TARGET_CC_ARCH}
--sysroot=%SDKTARGETSYSROOT%' >> $script
@@ -94,13 +94,13 @@ toolchain_shared_env_script_sdkmingw32 () {
EOF
}
-toolchain_create_sdk_siteconfig_append_sdkmingw32 () {
+toolchain_create_sdk_siteconfig:append:sdkmingw32 () {
# Make the file windows friendly...
awk 'sub("$", "\r")' $siteconfig > $siteconfig.new
mv $siteconfig.new $siteconfig
}
-toolchain_create_sdk_version_append_sdkmingw32 () {
+toolchain_create_sdk_version:append:sdkmingw32 () {
# Make the file windows friendly...
awk 'sub("$", "\r")' $versionfile > $versionfile.new
mv $versionfile.new $versionfile
diff --git a/conf/machine-sdk/include/mingw32-common.inc
b/conf/machine-sdk/include/mingw32-common.inc
index 3997a26..6c43fc9 100644
--- a/conf/machine-sdk/include/mingw32-common.inc
+++ b/conf/machine-sdk/include/mingw32-common.inc
@@ -1,6 +1,6 @@
SDK_OS = "mingw32"
-SDK_VENDOR_mingw32 = "-w64"
-SDK_VENDOR_sdkmingw32 = "-w64"
+SDK_VENDOR:mingw32 = "-w64"
+SDK_VENDOR:sdkmingw32 = "-w64"
NATIVESDKLIBC = "libc-mingw"
@@ -10,12 +10,12 @@ PREFERRED_PROVIDER_virtual/nativesdk-libc =
"nativesdk-mingw-w64-runtime"
PREFERRED_PROVIDER_virtual/nativesdk-libintl = "nativesdk-gettext"
PREFERRED_PROVIDER_virtual/nativesdk-libiconv = "nativesdk-libiconv"
-USE_NLS_mingw32 = "no&
[yocto] QA notification for completed autobuilder build (yocto-3.1.10.rc1)
A build flagged for QA (yocto-3.1.10.rc1) was completed on the autobuilder and is available at: https://autobuilder.yocto.io/pub/releases/yocto-3.1.10.rc1 Build hash information: bitbake: 0e0af15b84e07e6763300dcd092b980086b9b9c4 meta-agl: 68c0029602e539d005c33b6c36baa32e34bf67bf meta-arm: b79b9122e0dc66ca03542f82ff4fa8eb05174f61 meta-aws: d66de6ed82fe6b89e3b8b2626f4db6f5d7d5713d meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac meta-intel: d8bf86ae6288ae520b8ddd7209a0b448b9693f48 meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7 meta-openembedded: 8fbcfb9f023e0eab7f122eb19607a1c757b0d245 oecore: 9ae339ace9274be71bfd3b5e5da64dceac9fa963 poky: 2a848e95074318f3a243df7b3f40513a13173a82 This is an automated message from the Yocto Project Autobuilder Git: git://git.yoctoproject.org/yocto-autobuilder2 Email: richard.pur...@linuxfoundation.org -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54244): https://lists.yoctoproject.org/g/yocto/message/54244 Mute This Topic: https://lists.yoctoproject.org/mt/84493984/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] QA notification for completed autobuilder build (yocto-3.3.2.rc2)
A build flagged for QA (yocto-3.3.2.rc2) was completed on the autobuilder and is available at: https://autobuilder.yocto.io/pub/releases/yocto-3.3.2.rc2 Build hash information: bitbake: 731fb52eb03338c0bdb2a2256c22c64c22bcbace meta-agl: ee397d099bf5db91f14f357f874a0fb074208fbe meta-arm: 4e14a1c5ee84808cceb5354c6c26dd8ebe6696ce meta-aws: d66de6ed82fe6b89e3b8b2626f4db6f5d7d5713d meta-gplv2: 9e119f333cc8f53bd3cf64326f826dbc6ce3db0f meta-intel: 4c7eecf2550fca9136a332400be6da358d264cb6 meta-mingw: 422b96cb2b6116442be1f40dfb5bd77447d1219e meta-openembedded: 8fbcfb9f023e0eab7f122eb19607a1c757b0d245 oecore: e458c15627e7b27392d158cbb9417f66424aa7d5 poky: 31c639eb8664059eb4ed711be9173c223b4cc940 This is an automated message from the Yocto Project Autobuilder Git: git://git.yoctoproject.org/yocto-autobuilder2 Email: richard.pur...@linuxfoundation.org -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54237): https://lists.yoctoproject.org/g/yocto/message/54237 Mute This Topic: https://lists.yoctoproject.org/mt/84483428/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [yocto-autobuilder-helper] [PATCH] config.json: Update to use new overrides syntax
To help with the conversion, switch the core configurations to use the new
syntax since this allows testing with the new syntax only.
Signed-off-by: Richard Purdie
---
config.json | 94 ++---
1 file changed, 47 insertions(+), 47 deletions(-)
diff --git a/config.json b/config.json
index 8464da4..6efef34 100644
--- a/config.json
+++ b/config.json
@@ -35,7 +35,7 @@
"SDKEXTRAS" : ["SSTATE_MIRRORS += '\\", "file://.*
http://sstate.yoctoproject.org/dev/@RELEASENUM@PATH;downloadfilename=PATH'"],
"BUILDINFO" : false,
"BUILDHISTORY" : false,
-"BUILDINFOVARS" : ["INHERIT += 'image-buildinfo'",
"IMAGE_BUILDINFO_VARS_append = ' IMAGE_BASENAME IMAGE_NAME'"],
+"BUILDINFOVARS" : ["INHERIT += 'image-buildinfo'",
"IMAGE_BUILDINFO_VARS:append = ' IMAGE_BASENAME IMAGE_NAME'"],
"WRITECONFIG" : true,
"SENDERRORS" : true,
"extravars" : [
@@ -48,9 +48,9 @@
"XZ_MEMLIMIT = '5%'",
"XZ_THREADS = '8'",
"BB_TASK_NICE_LEVEL = '5'",
-"BB_TASK_NICE_LEVEL_task-testimage = '0'",
+"BB_TASK_NICE_LEVEL:task-testimage = '0'",
"BB_TASK_IONICE_LEVEL = '2.7'",
-"BB_TASK_IONICE_LEVEL_task-testimage = '2.1'",
+"BB_TASK_IONICE_LEVEL:task-testimage = '2.1'",
"INHERIT += 'testimage'",
"TEST_QEMUBOOT_TIMEOUT = '1500'",
"SANITY_TESTED_DISTROS = ''",
@@ -71,7 +71,7 @@
"BUILDINFO" : true,
"BUILDHISTORY" : true,
"extravars" : [
-"IMAGE_INSTALL_append = ' ssh-pregen-hostkeys'"
+"IMAGE_INSTALL:append = ' ssh-pregen-hostkeys'"
],
"step1" : {
"BBTARGETS" : "core-image-sato core-image-sato-sdk
core-image-minimal core-image-minimal-dev core-image-sato:do_populate_sdk",
@@ -94,7 +94,7 @@
"BUILDINFO" : true,
"BUILDHISTORY" : true,
"extravars" : [
-"IMAGE_INSTALL_append = ' ssh-pregen-hostkeys'"
+"IMAGE_INSTALL:append = ' ssh-pregen-hostkeys'"
],
"step1" : {
"BBTARGETS" : "core-image-full-cmdline core-image-sato
core-image-sato-sdk",
@@ -122,11 +122,11 @@
"BBTARGETS" : "core-image-sato",
"SANITYTARGETS" : "core-image-sato:do_testimage",
"extravars" : [
-"IMAGE_INSTALL_append = ' ltp'",
+"IMAGE_INSTALL:append = ' ltp'",
"TEST_SUITES = 'ping ssh ltp ltp_compliance'",
"IMAGE_OVERHEAD_FACTOR = '1.0'",
"IMAGE_ROOTFS_EXTRA_SPACE = '1324288'",
-"QB_MEM_forcevariable = '-m 1024'"
+"QB_MEM:forcevariable = '-m 1024'"
]
},
"arch-hw" : {
@@ -180,7 +180,7 @@
"PACKAGE_CLASSES" : "package_rpm",
"extravars" : [
"RPM_GPG_SIGN_CHUNK = '1'",
-"IMAGE_INSTALL_append = ' ssh-pregen-hostkeys'"
+"IMAGE_INSTALL:append = ' ssh-pregen-hostkeys'"
],
"step1" : {
"shortname" : "Bitbake Selftest",
@@ -436,7 +436,7 @@
"TEMPLATE" : "arch-qemu",
"step1" : {
"extravars" : [
- "IMAGE_FSTYPES_append = ' wic wic.bmap'"
+ "IMAGE_FSTYPES:append = ' wic wic.bmap'"
]
}
},
@@ -449,7 +449,7 @@
"TEMPLATE" : "arch-hw",
"step1" : {
"extravars" : [
- "IMAGE_FSTYPES_append = ' wic wic.bmap'"
+ "IMAGE_FSTYPES:append = ' wic wic.bmap'"
]
}
},
@@ -462,7 +462,7 @@
"TEMPLATE" : "arch-qemu&q
Re: [yocto] [PATCH yocto-autobuilder-helper] Enable canary builds for meta-aws[aws-iot-device-sdk-cpp-v2] on x86-64 and arm64.
On Thu, 2021-07-22 at 17:29 -0400, elberger via lists.yoctoproject.org wrote:
> From: Richard Elberger
>
> This patch provides the buildbot system to make the aws-iot-device-sdk-cpp-v2.
> - build on poky
> - meta-openembedded and meta-aws are additional repo dependencies
> - build for the two dominant architectures: x86-64 and arm64.
>
> Signed-off-by: Richard Elberger
> ---
> config.json | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/config.json b/config.json
> index 3709b40..f04fac8 100644
> --- a/config.json
> +++ b/config.json
> @@ -350,6 +350,23 @@
> "BBTARGETS": "agl-image-core-autobuilder"
> }
> },
> +"meta-aws" : {
> +"NEEDREPOS" : ["poky", "meta-openembedded", "meta-aws"],
> +"ADDLAYER" : [
> +"${BUILDDIR}/../meta-openembedded/meta-oe",
> +"${BUILDDIR}/../meta-openembedded/meta-networking",
> +"${BUILDDIR}/../meta-openembedded/meta-python",
> +"${BUILDDIR}/../meta-aws"
The ordering isn't correct here since they have to be added in dependency
order and for some reason this was different to the patch we discussed
previously. I've just gone ahead and fixed it.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54206): https://lists.yoctoproject.org/g/yocto/message/54206
Mute This Topic: https://lists.yoctoproject.org/mt/84387478/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [PATCH yocto-autobuilder-helper] Enable canary builds for meta-aws[aws-iot-device-sdk-cpp-v2] on x86-64 and arm64.
On Thu, 2021-07-22 at 16:05 -0400, elberger via lists.yoctoproject.org wrote: > Hello, > > What can I do to move this patch along - or did I miss anything? > Apologies for my ignorance, it's my first time submitting a patch to YP. I can't see the patch in the mailing list archives: https://lists.yoctoproject.org/g/yocto/topics? only your reply: https://lists.yoctoproject.org/g/yocto/topic/patch/84387478? so I don't think the original patch made it to the list? Since I never saw it there, I couldn't apply it! Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54197): https://lists.yoctoproject.org/g/yocto/message/54197 Mute This Topic: https://lists.yoctoproject.org/mt/84387478/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] QA notification for completed autobuilder build (yocto-3.4_M2.rc1)
A build flagged for QA (yocto-3.4_M2.rc1) was completed on the autobuilder and is available at: https://autobuilder.yocto.io/pub/releases/yocto-3.4_M2.rc1 Build hash information: bitbake: 13e2855bff6a6ead6dbd33c5be4b988aafcd4afa meta-arm: 9efa3b5683a5dd7ebbf63ff31b889ed589ff7a9a meta-gplv2: b3fa26bc777ec0136ce189d90123b50f6ee567b9 meta-intel: 94c097a82cf9167fa567c2af80d5e39a3fbbc11f meta-mingw: 8f3b6e3772879dc2caec8fe249ce277fbb1aa55f oecore: c4fc226c2e3856b942bb4f57ead21a64c3dc8c0d poky: 1ad79313a5c3e6a453fbeb44caac5c5bbad46d3c [RP sending manually as the original failed to get through] This is an automated message from the Yocto Project Autobuilder Git: git://git.yoctoproject.org/yocto-autobuilder2 Email: richard.pur...@linuxfoundation.org -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54176): https://lists.yoctoproject.org/g/yocto/message/54176 Mute This Topic: https://lists.yoctoproject.org/mt/84352671/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [layerindex-web][PATCH 00/15] Upgrade to Django 3.2.5 LTS and Celery 5
On Sun, 2021-07-18 at 16:07 -0700, Tim Orling wrote: > The current code base uses Django 2.2.x which will go out of extended > support in April 2022, but also holds us back from updating a number of > dependencies. > > Update to the current Django 3.2.5 LTS and also the latest Celery 5.1.2. > Celery 4 has not had any commits since 2020 and is unlikely to be > getting much more attention from the developers. > > While we are at it, upgrade all of our dependencies to the latest > versions. I don't have the skills to review this in detail but it sounds like a good step forward for many different reasons, thanks! Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54173): https://lists.yoctoproject.org/g/yocto/message/54173 Mute This Topic: https://lists.yoctoproject.org/mt/84296948/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Exception: NotADirectoryError building Hardknott
On Sun, 2021-07-18 at 14:01 +1000, Simon Haines wrote: > I can't seem to find any information about this error, but I keep getting > variations of this when building > hardknott: > > Exception: NotADirectoryError: [Errno 20] Not a directory: > '/home/yocto/rpi64/build/tmp/sysroots- > components/x86_64/gmp-native/usr/lib/pkgconfig/gmpxx.pc' -> > '/home/yocto/rpi64/build/tmp/work/x86_64- > linux/libmpc-native/1.2.1-r0/recipe-sysroot-native/usr/lib/pkgconfig/gmpxx.pc' > > I'm building in a container, and I've tried building the tip of the hardknott > branch, the hardknott-3.3.1 > tag, and the release tarball ( > http://downloads.yoctoproject.org/releases/yocto/yocto-3.3/poky-hardknott-25.0.0.tar.bz2). > All fail with the > NotADirectory exception in different recipes. I've attached logs from > building the hardknott-3.3.1 tag and > from the release tarball. > > The additional layers I'm using are (cloned from the tip of their respective > hardknott branches): > meta-openembedded > meta-raspberrypi > meta-security > > It must be something with my setup because I've searched everywhere for this > issue and I can't find > anything. Does this sound familiar to anyone? How is your container filesystem setup/configured? It looks like the filesystem isn't liking the build trying to create hardlinked files. It is odd it would get as far as gmp-native before having problems. That file definitely isn't a directory too, it is an odd error. I'd suspect it is something like the copy-on-write mode of the filesystem having issues. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54142): https://lists.yoctoproject.org/g/yocto/message/54142 Mute This Topic: https://lists.yoctoproject.org/mt/84281972/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [yocto-autobuilder-helper] [PATCH] config.json: Use pregen-hostkeys on all qemu targets
Rather than just ppc/mips, use the pregen-hostkeys on all the qemu targets
since this is using a lot of time on the autobuilders when we don't really
need to. This should avoid some of the testing failures seen on qemuarm
recently.
Signed-off-by: Richard Purdie
---
config.json | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/config.json b/config.json
index 4f6044e..1c52d60 100644
--- a/config.json
+++ b/config.json
@@ -71,6 +71,9 @@
"arch-qemu" : {
"BUILDINFO" : true,
"BUILDHISTORY" : true,
+"extravars" : [
+"IMAGE_INSTALL_append = ' ssh-pregen-hostkeys'"
+],
"step1" : {
"BBTARGETS" : "core-image-sato core-image-sato-sdk
core-image-minimal core-image-minimal-dev core-image-sato:do_populate_sdk",
"SANITYTARGETS" : "core-image-minimal:do_testimage
core-image-sato:do_testimage core-image-sato-sdk:do_testimage
core-image-sato:do_testsdk"
@@ -91,6 +94,9 @@
"DISTRO" : "poky-altcfg",
"BUILDINFO" : true,
"BUILDHISTORY" : true,
+"extravars" : [
+"IMAGE_INSTALL_append = ' ssh-pregen-hostkeys'"
+],
"step1" : {
"BBTARGETS" : "core-image-full-cmdline core-image-sato
core-image-sato-sdk",
"SANITYTARGETS" : "core-image-full-cmdline:do_testimage
core-image-sato:do_testimage core-image-sato-sdk:do_testimage"
@@ -383,16 +389,10 @@
},
"qemumips" : {
"MACHINE" : "qemumips",
-"extravars" : [
-"IMAGE_INSTALL_append = ' ssh-pregen-hostkeys'"
-],
"TEMPLATE" : "arch-qemu"
},
"qemumips-alt" : {
"MACHINE" : "qemumips",
-"extravars" : [
-"IMAGE_INSTALL_append = ' ssh-pregen-hostkeys'"
-],
"TEMPLATE" : "altcfg-qemu"
},
"edgerouter" : {
@@ -409,16 +409,10 @@
},
"qemuppc" : {
"MACHINE" : "qemuppc",
-"extravars" : [
-"IMAGE_INSTALL_append = ' ssh-pregen-hostkeys'"
-],
"TEMPLATE" : "arch-qemu"
},
"qemuppc-alt" : {
"MACHINE" : "qemuppc",
-"extravars" : [
-"IMAGE_INSTALL_append = ' ssh-pregen-hostkeys'"
-],
"TEMPLATE" : "altcfg-qemu"
},
"qemux86" : {
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54112): https://lists.yoctoproject.org/g/yocto/message/54112
Mute This Topic: https://lists.yoctoproject.org/mt/84174781/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [error-report-web][PATCH] report-error.bbclass: Add layer and bitbake version info to error report
On Fri, 2021-07-09 at 14:07 +0530, Milan Shah wrote: > Well, there was no update on the bug as well as on the patch so I was > not aware of it. > > Thanks, Richard for responding. I'll definitely follow your suggestion > next time. We'd normally expect the bug owner to update the status of the bug since it isn't really possible for me or the triage team to track and update them all. We can close this one with a link to the commit: http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/report-error.bbclass?id=8b299a62c55aa8d1583aff4b8428f16def7231b7 Happy for you to, or I can... Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54084): https://lists.yoctoproject.org/g/yocto/message/54084 Mute This Topic: https://lists.yoctoproject.org/mt/79474306/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [error-report-web][PATCH] report-error.bbclass: Add layer and bitbake version info to error report
On Fri, 2021-07-09 at 10:51 +0530, Milan Shah wrote: > Hello All, > > My Patch has not been reviewed for the past 7 months. Looking forward > to see some updates on this. > > Please find related links below. > https://lists.yoctoproject.org/g/yocto/message/51891 > https://bugzilla.yoctoproject.org/show_bug.cgi?id=9700 > http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/report-error.bbclass?id=8b299a62c55aa8d1583aff4b8428f16def7231b7 It appears to have merged 5 months ago? Also, looking at the patch that inherit base should not be there and needs to be removed since everything always inherits base. In the future please send OE-Core changes to the openembedded-core mailing list as that will speed up review and patch handling (as per the repo's README). Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54082): https://lists.yoctoproject.org/g/yocto/message/54082 Mute This Topic: https://lists.yoctoproject.org/mt/79474306/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [Yocto] Launching script at the very end of the image process
On Wed, 2021-06-30 at 10:41 +, Cardaillac, Yann wrote:
> Hi Richard,
>
> Many thanks for the fast answer.
>
> > > I’m switching from buildroot to yocto and trying to figure out how to
> > > do the equivalent of a POST_BUILD_SCRIPT.
> > >
> > > Indeed I want to format the images built in a specific format for latter
> > > use and CI needs.
> >
> > In OE, the equivalent for that is probably the image types code.
> > See
> > http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/image_types.bbclass
> >
> > You can define your own custom image types to extend the system. Some of
> > our defaults are quite simple (tar), some are quite complex (wic has its
> > own bbclass).
>
> I said image, but it was probably not the best word, I just want to make a
> tarball
> of the generated image + adding some file in it.
>
> Here's the complete file with the job :
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
>
> SRC_URI += "file://nallino-custom-params.txt"
> SRC_URI += "file://configuration_instruction_to_do_on_GUF.txt"
>
> do_release_ycn() {
>
> rm -rf ${DEPLOY_DIR_IMAGE}/ycn_release
> mkdir -p ${DEPLOY_DIR_IMAGE}/ycn_release/overlays
> cp ${DEPLOY_DIR_IMAGE}/fng-install.sh ${DEPLOY_DIR_IMAGE}/ycn_release
> cp ${DEPLOY_DIR_IMAGE}/ycn-image-imx6ullguf.tar.gz
> ${DEPLOY_DIR_IMAGE}/ycn_release/guf-image-imx6ullguf.tar.gz
> cp ${DEPLOY_DIR_IMAGE}/*.dtbo ${DEPLOY_DIR_IMAGE}/ycn_release/overlays
> cp ${WORKDIR}/nallino-custom-params.txt ${DEPLOY_DIR_IMAGE}/ycn_release/
> cp ${WORKDIR}/configuration_instruction_to_do_on_GUF.txt
> ${DEPLOY_DIR_IMAGE}/ycn_release/
> tar -czf ${DEPLOY_DIR_IMAGE}/ycn_release.tar.gz
> ${DEPLOY_DIR_IMAGE}/ycn_release
>
> }
> addtask release_ycn after do_image_complete after do_deploy_kernelmodules
>
You're used to poking around things in buildroot, OE doesn't quite like you
doing that so much :)
You shouldn't really be poking around DEPLOY_DIR without letting the build
system know what you're doing. Intermediate files like the intermediate
directory
you're using to create the tarball above should really be in WORKDIR.
That is itself won't break, it just not good practise. Ideally you'd write
a separate recipe to do this final piece with a do_deploy task, using the
deploy bbclass which would them take care of removing obsolete versions
when you rebuild and so on.
> > > I’ve also tried to use IMAGE_POSTPROCESS_COMMAND without much success
> > > since it wasn’t running at the proper moment.
>
> > When is "the right moment"? :)
>
> The right moment, is at the very end of bitbake, indeed I want the job
> to be the overall last job!
You're not really helping us help you find a solution since you've not described
what you'd expect to be happening that isn't happening. How is what you have
failing?
I'm going to take a leap and guess that some of the files you expect there
aren't? Maybe the dtbo files from some other do_deploy tasks? If that is true
you're missing dependencies for your task. You can do things like:
do_release_ycn[depends] += "virtual/kernel:do_deploy"
I'd caution against "last" as it is a fine concept until two things want to
be "last". It is usually better to describe the dependencies properly.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54018): https://lists.yoctoproject.org/g/yocto/message/54018
Mute This Topic: https://lists.yoctoproject.org/mt/83888533/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [Yocto] Launching script at the very end of the image process
On Wed, 2021-06-30 at 09:33 +, Cardaillac, Yann wrote: > I’m switching from buildroot to yocto and trying to figure out how to do the > equivalent of a > POST_BUILD_SCRIPT. > > Indeed I want to format the images built in a specific format for latter use > and CI needs. In OE, the equivalent for that is probably the image types code. See http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/image_types.bbclass You can define your own custom image types to extend the system. Some of our defaults are quite simple (tar), some are quite complex (wic has its own bbclass). > I’ve also tried to use IMAGE_POSTPROCESS_COMMAND without much success since > it > wasn’t running at the proper moment. When is "the right moment"? :) Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54016): https://lists.yoctoproject.org/g/yocto/message/54016 Mute This Topic: https://lists.yoctoproject.org/mt/83888533/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [OE-core] Hardknott (GCC10) Compiler Issues
On Thu, 2021-06-24 at 21:48 -0700, Chuck Wolber wrote: > All, > > Please accept my apologies in advance for the detailed submission. I think > it is warranted in this case. > > There is something... "odd" about the GCC 10 compiler that is delivered with > Hardknott. I am still chasing it down, so I am not yet ready to declare a > root cause or submit a bug, but I am posting what I have now in case anyone > has some insights to offer. The issue you describe does sound strange. I was a little unclear about exactly which combinations were passing/failing. Are you saying that some versions of buildtools let the system work but some do not? We now have gcc 11 in master so it would be interesting to know how things worked there and if any regression was fixed. I have also heard reports of issues with bison segfaulting from other sources but I don't have anything I can point to specifically about it. The target system should be independent of buildtools version and the target system should also be binary reproducible so if that were changing through changing buildtools tarball, that would be worrying in itself. > P.P.S. For the sake of completeness, I had to add the following files to the > buildtools-extended > sysroot to fully complete the build of our images: > > /usr/include/magic.h -> util-linux "more" command requires this. > /usr/include/zstd.h -> I do not recall which recipe required this. > /usr/bin/free -> The OpenJDK 8 build scripts need this. > /usr/include/sys/* -> openjdk-8-native > /lib/libcap.so.2 -> The binutils "dir" command quietly breaks the build > without this. I am not a fan of the > lack of error checking in the binutils build... > /usr/include/sensors/error.h and sensors.h -> mesa-native > /usr/include/zstd_errors.h -> qemu-system-native It is great to have this list, outside the non-jdk issues are probably issues we should look at fixing in OE-Core. Do you mean binutils above for the dir command? Cheers, -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53989): https://lists.yoctoproject.org/g/yocto/message/53989 Mute This Topic: https://lists.yoctoproject.org/mt/83843656/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] The do_populate_sdk is finishing OK even when there are errors present in the build
On Thu, 2021-06-24 at 17:40 -0300, Fabio Berton wrote: > Hi all! > > I'm running some test with do_populate_sdk task and I'm seeing this > on the log: > > check_data_file_clashes: Package kmsxx-dbg wants to install file > /home/builder/build/tmp/work/foo-poky- > linux/core-image-minimal/1.0-r0/sdk/image/opt/bar/sysroots/aarch64-poky-linux/usr/bin/.debug/kmstest > But that file is already provided by package * libdrm-dbg > > I also see this kind of message with other packages. > > Looking in the source code I found that the install_complementary > function runs this [1] with attempt_only=True, and if attempt_only is > true log above it's just a warning, as shown here [2]. > > This [3] comment says that "will only attempt to install these packages, > if they don't exist then no error will occur." > > My question is how can I force an error and not just a warning when > running do_populate_sdk? > > I understand that I can change [1] to run: > > self.install(install_pkgs) > > so, it'll use set attempt_only to False, that is the default, but I > think this will break some use cases. > > What is the correct behaviour here, see the warning messages and fix > the packages to avoid "file is already provided by package" messages, > every time I create a SDK or change in some way to see an error message > and stop SDK generation? > > What is the correct behavior here, inspect the warning messages, and > fix the packages to avoid "file is already provided by package" messages, > every time I create an SDK or change it in some way to see an error > message and stop the SDK generation? It would probably be worth an experiment to see if we really do need the attempt_only option set there any more. I'd hope it isn't needed now... It is probably worth testing a patch on the autobuilder, assuming your local tests with that pass. We'd need to check the different package backends are ok with that. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53976): https://lists.yoctoproject.org/g/yocto/message/53976 Mute This Topic: https://lists.yoctoproject.org/mt/83769900/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] what's the state of things with pushing the bounds on ASSUME_PROVIDED?
On Thu, 2021-06-24 at 07:50 -0400, Robert P. J. Day wrote: > i asked about this once upon a time, so i thought i'd follow up ... > given the fairly stable state of recent linux distros, is there any > standard for taking advantage of what *should* be robust native tools > rather than building them? (i'm ignoring taking advantage of sstate > and building SDKs and other clever speedups for now.) > > from scratch, i did a wind river (LINCD) build of > wrlinux-image-small (and i assume it would be much the same under > current oe-core), and i notice that numerous native tools were > compiled, including such standards as cmake, curl, elfutils ... the > list goes on and on. > > so other than the tools that are *required* to be installed, if i > mention that i am currently running ubuntu 20.04, is there any > indication as to which tools i'm relatively safe to take advantage > using ASSUME_PROVIDED and HOSTTOOLS? i realize that the versions built > will probably differ from the host versions, but it seems that if > there is an incompatibility, that would be fairly obvious in short > order. > > thoughts? Quite often things aren't as simple as they first seem: Elfutils has a history of interesting changes between versions so having our builds use a consistent version is good. Some recipes build libs as well as binaries, e.g. the compression tools. Its relatively easy to check a binary is present, it is harder to check the right -devel headers are present. That is a solvable problem but again, version consistency is good. If you require a HOSTTOOLS bin but our own lib, you can get version mismatches. We do patch some utilities for 'reasons' and having those patches missing can be a pain and cause weird errors. Reproducibility is also a concern, particularly if different versions of tools like flex/bison generated different code. I also wonder who is going to support testing all these different options and handle the resulting build failures and bugs being raised? This list isn't definitive. In summary, I see a lot of problems for what amounts to not much speed gain. Particularly when we have a mechanism like sstate available which allows binary reuse. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53975): https://lists.yoctoproject.org/g/yocto/message/53975 Mute This Topic: https://lists.yoctoproject.org/mt/83758672/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [PATCH yocto-autobuilder-helper] summarize_top_output.py: add script, use it and publish summary
On Wed, 2021-06-16 at 04:43 -0400, sakib.sa...@windriver.com wrote:
> summarize_top_output.py is used to summarize the top
> output that is captured during autobuilder intermittent
> failures.
>
> Use the script to summarize the host top output and
> publish the summary that is created instead of
> the raw logfile.
>
>
>
[...]
> if jcfg:
> diff --git a/scripts/summarize_top_output.py b/scripts/summarize_top_output.py
> new file mode 100755
> index 000..0606a34
> --- /dev/null
> +++ b/scripts/summarize_top_output.py
> @@ -0,0 +1,132 @@
> +#!/usr/bin/env python3
> +
> +import os, sys, glob
> +
> +# constants
> +top_header = 7
> +top_summary = 5
> +max_cols = 11
> +
> +# string substitution to make things easier to read
> +subs = {
> +"/home/pokybuild/yocto-worker/" : "~/",
> +"/build/build/tmp/work/core2-32-poky-linux/" : "/.../POKY_32/.../",
> +"/build/build/tmp/work/core2-64-poky-linux/" : "/.../POKY_64/.../",
> +
> "/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/"
> : "/...GCC.../"
> +}
One quick question - the above assumes an x86 target machine using those two
tunes.
Should that be wildcarded?
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53893): https://lists.yoctoproject.org/g/yocto/message/53893
Mute This Topic: https://lists.yoctoproject.org/mt/83576331/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [poky] [PATCH] local.conf.sample: disable prelink
On Tue, 2021-06-15 at 17:21 +0200, Alexander Kanavin wrote: > So the memory usage is actually *better* without prelink. And any timing > benefits are lost in statistical noise, in these tests at least. The numbers certainly don't look convincing, thanks for running the tests. > So I do not think it is wrong to question the usefulness of this feature. > I'd like to hear Mark's take on this, as prelink-cross is primarily his > work, he's put a lot of effort into it, and I would want to know where > the benefits are. Note that Red Hat abandoned prelink in 2013, and > prelink-cross likewise hasn't seen any commits for two years. Mark and I did briefly talk yesterday and whilst Mark can/will speak up, the summary was "drop it". What makes me sad is that this is an embedded focused feature which the project should be caring about, i.e. memory footprint and speed. I don't know why the numbers don't show it, Mark and I have theories but it would take work to explore them and neither of us have that time, nor are we experts on prelink able to maintain it with the time we have available. In my view the project should be caring about things like this, instead it looks more like a race to look like 'any other desktop distro' and drop anything which looks different. I've tried to say no. Nobody else would appear to care, I'm hearing silence. I can't fight this. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53886): https://lists.yoctoproject.org/g/yocto/message/53886 Mute This Topic: https://lists.yoctoproject.org/mt/83558267/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [meta-java] icedtea7 fetching error
On Mon, 2021-06-14 at 21:31 +, Richard Leitner - SKIDATA wrote: > On Mon, Jun 14, 2021 at 09:29:05PM +0100, Richard Purdie wrote: > > On Mon, 2021-06-14 at 20:20 +, Richard Leitner - SKIDATA wrote: > > > On Thu, Jun 10, 2021 at 10:57:46AM +0200, Alexander Kanavin wrote: > > > > I have the tarball. I think we should toss it somewhere safe and update > > > > the > > > > recipe, as it is unlikely the old mercurial repo is coming back. > > > > > > > > Suggestions? > > > > > > Sorry for the late reply, I was on vacation 😉. > > > > > > Nothing that comes to my mind directly. Do you know of any hosting > > > possibilites from YP or OE-Core? > > > > > > @Richard: Sorry for putting you in that conversation without warning... > > > But maybe you may guide us in a direction where to host/mirror some > > > "legacy" > > > meta-java source tarballs? > > > > If someone points me at the tarballs I can probably sort something out with > > our source mirrors. > > Thank you very much Richard! > The openjdk8 tarballs are now hosted at > https://downloads.yoctoproject.org/mirror/sources/ > with their local download names. > > Unfortunately I currently don't have the time and resources to provide a > patch for fixing the URLs and adding the mirror. > So help is greatly appreciated! In theory if these are the names the metadata was using and you have the standard OE/Yocto source mirrors, this should "just work"... Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53867): https://lists.yoctoproject.org/g/yocto/message/53867 Mute This Topic: https://lists.yoctoproject.org/mt/83390307/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [meta-java] icedtea7 fetching error
On Mon, 2021-06-14 at 20:20 +, Richard Leitner - SKIDATA wrote: > On Thu, Jun 10, 2021 at 10:57:46AM +0200, Alexander Kanavin wrote: > > I have the tarball. I think we should toss it somewhere safe and update the > > recipe, as it is unlikely the old mercurial repo is coming back. > > > > Suggestions? > > Sorry for the late reply, I was on vacation 😉. > > Nothing that comes to my mind directly. Do you know of any hosting > possibilites from YP or OE-Core? > > @Richard: Sorry for putting you in that conversation without warning... > But maybe you may guide us in a direction where to host/mirror some "legacy" > meta-java source tarballs? If someone points me at the tarballs I can probably sort something out with our source mirrors. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53864): https://lists.yoctoproject.org/g/yocto/message/53864 Mute This Topic: https://lists.yoctoproject.org/mt/83390307/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Extensible SDK of core-image-minimal fails to install
On Fri, 2021-06-11 at 22:30 +0200, Hendrik wrote: > I was able to reproduce the error even with plain poky (without kas): > > ```bash > git clone -b dunfell https://git.yoctoproject.org/git/poky > cd poky > source oe-init-build-env > bitbake -c populate_sdk_ext core-image-minimal > ``` > > After successful build, copy the `build/tmp/deploy/sdk/pokysh` to > another machine (with different OS) and run it there. > > I tried several different installation machines and they fail > consistently to install the extensible SDK if they run a different OS > than the build machine (e.g. Debian 10 vs. Ubuntu 18.04 vs. 20.04). See > the exakt error and complete log output in my previous message. > > What is happening here? Did I use the extensible SDK wrongly? Is it > expected to be incompatible? I think it may be this bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14428 We don't have a fix as yet, it looks difficult to solve :( Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53845): https://lists.yoctoproject.org/g/yocto/message/53845 Mute This Topic: https://lists.yoctoproject.org/mt/83423927/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [ANNOUNCEMENT] Yocto Project 3.3.1 (hardknott-25.0.1) is Released
On Tue, 2021-05-25 at 12:13 +, Peter Kjellerstedt wrote: > It seems the ”hardknott-25.0.1” tag is missing for meta-gplv2. > The “yoccto-3.3.1” tag is present. This was deliberate since we've been trying to step away from the "poky" version numbers, I'm not sure they add much to anything. Is there a particular reason you were looking for those? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53643): https://lists.yoctoproject.org/g/yocto/message/53643 Mute This Topic: https://lists.yoctoproject.org/mt/83064462/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: VS: [yocto] Make do_image_complete wait for an earlier task
On Tue, 2021-05-18 at 07:09 +, Mikko Murto wrote: > > Lähettäjä: Richard Purdie > > Lähetetty: tiistai 18. toukokuuta 2021 9.57 > > > > On Tue, 2021-05-18 at 06:15 +, Mikko Murto wrote: > > > Hi, > > > > > > I've created a task do_create_spdx that gets some data from packages > > > after do_package. The task is currently added with `addtask > > > do_create_spdx after do_package before do_packagedata` The data is > > > then enriched and combined in do_image_complete by adding the combining > > function to IMAGE_POSTPROCESS_COMMAND. > > > For the most part everything works as expected, but for some packages > > > do_create_spdx does not complete in time for the combination step in > > do_image_complete. > > > Is there a way for me force do_image_complete to wait for > > > do_create_spdx to have been completed for all packages? > > > > This seems a little odd since image.bbclass has: > > > > do_rootfs[recrdeptask] += "do_packagedata" > > > > which means do_rootfs should only happen after all do_packagedata have run. > > Your task is added before do_packagedata. > > do_image and do_image_complete should run after do_rootfs. > > > > I'm wondering if the issue is more to do with reuse of previous build > > artefacts > > where sstate is involved. Does your added task account for sstate? > > That is odd indeed. I need to give it another go. As for accounting for > sstate, > no, at least not intentionally. I don't have much to go on but guessing, if you run some test and then rerun that test, the second build would come from sstate. If a build comes from sstate, it will skip tasks that precede the sstate artefact. More specifically, if sstate exists for do_packagedata, it would skip any tasks preceeding that task including your do_create_spdx task. There is no direct dependency from do_image_complete on the do_create_spdx tasks. You can add: do_rootfs[recrdeptask] += "do_create_spdx" but this will have the side effect that the build will never use sstate and always rebuild since that task isn't an sstate task. > > I've been giving some thought to SDPX and SBOM during our build process so I > > am curious what you're doing, is the work public anywhere? > > Public at https://github.com/doubleopen-project/meta-doubleopen. The usual > disclaimers about PoC-level spaghetti apply; all questions and comments > very much appreciated! 😊 I did have a quick look and you're going further than I'd been thinking of, at least initially. What I'm thinking of in core YP initially is to have do_packagedata generate SPDX data for the output packaged files in do_package/do_packagedata. I noticed you go further and process all the input sources and I'm not sure we're ready to do that yet. Doing it at do_package/do_packagedata time would still access any of the sources included from a debug perspective, hence it should correctly find the shipped manifest/license info without the complexity of having to scan all the sources For your level of source scanning, I'd look at the existing do_populate_lic task which is sstate and generates license info. I think I'd be in favour of totally replacing that with something generating spdx output... I'm actually hoping we could simply what we're doing today however the more I look at all the information you can put into SPDX, the more I worry that whilst we can generate tons of data and huge SPDX files, I'm not sure they're actually useful to anyone to actually use :/. For the SBOM information, we do need to somehow make something as useful as our normal manifest to people for this to be useful and adopted, at least from my perspective. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53561): https://lists.yoctoproject.org/g/yocto/message/53561 Mute This Topic: https://lists.yoctoproject.org/mt/82906475/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Make do_image_complete wait for an earlier task
On Tue, 2021-05-18 at 06:15 +, Mikko Murto wrote: > Hi, > > I've created a task do_create_spdx that gets some data from packages after > do_package. The task is currently added with `addtask do_create_spdx after > do_package before do_packagedata` The data is then enriched and combined in > do_image_complete by adding the combining function to > IMAGE_POSTPROCESS_COMMAND. > For the most part everything works as expected, but for some packages > do_create_spdx does not complete in time for the combination step in > do_image_complete. > Is there a way for me force do_image_complete to wait for do_create_spdx to > have been > completed for all packages? This seems a little odd since image.bbclass has: do_rootfs[recrdeptask] += "do_packagedata" which means do_rootfs should only happen after all do_packagedata have run. Your task is added before do_packagedata. do_image and do_image_complete should run after do_rootfs. I'm wondering if the issue is more to do with reuse of previous build artefacts where sstate is involved. Does your added task account for sstate? I've been giving some thought to SDPX and SBOM during our build process so I am curious what you're doing, is the work public anywhere? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53558): https://lists.yoctoproject.org/g/yocto/message/53558 Mute This Topic: https://lists.yoctoproject.org/mt/82905995/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Opencv build generates Pseudo Abort
On Mon, 2021-05-17 at 13:25 +0200, Morten Bruun wrote:
> Hi,
>
> When building on the new hardknott branch I often get the error below, so far
> the solution is to delete the
> tmp directory. Any suggestions?
>
> debug_logfile: fd 2
> pid 6668 [parent 6667], doing new pid setup and server start
> Setup complete, sending SIGUSR1 to pid 6667.
> creat for '
> /tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/opencv/4.5.2-
> r0/package/usr/lib/stMOsGHa' replaces existing 11214613 ['
> /tmp/work/cortexa7t2hf-neon-vfpv4-poky-
> linux-gnueabi/opencv/4.5.2-r0/package/usr/lib/libopencv_xfeatures2d.so.4.5.2'].
> creat for '
> /tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/opencv/4.5.2-
> r0/package/usr/lib/stUxt79H' replaces existing 11214665 ['
> /tmp/work/cortexa7t2hf-neon-vfpv4-poky-
> linux-gnueabi/opencv/4.5.2-r0/package/usr/lib/libopencv_sfm.so.4.5.2'].
> creat for '
> /tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/opencv/4.5.2-
> r0/package/usr/lib/staYWmKL' replaces existing 11214480 ['
> /tmp/work/cortexa7t2hf-neon-vfpv4-poky-
> linux-gnueabi/opencv/4.5.2-r0/package/usr/lib/libopencv_imgproc.so.4.5.2'].
> db cleanup for server shutdown, 00:12:21.579
> memory-to-file backup complete, 00:12:21.579.
> db cleanup finished, 00:12:21.579
> debug_logfile: fd 2
> pid 4234 [parent 4192], doing new pid setup and server start
> Setup complete, sending SIGUSR1 to pid 4192.
> db cleanup for server shutdown, 00:19:10.704
> memory-to-file backup complete, 00:19:10.705.
> db cleanup finished, 00:19:10.705
> debug_logfile: fd 2
> pid 17609 [parent 17585], doing new pid setup and server start
> Setup complete, sending SIGUSR1 to pid 17585.
> path mismatch [3 links]: ino 12076677 db
>
This is the key part of the log:
> /tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/opencv/4.5.2-
> r0/package/usr/src/debug/opencv/4.5.2-
> r0/contrib/modules/intensity_transform/include/opencv2/intensity_transform.hpp'
> req
> '/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/opencv/4.5.2-
> r0/contrib/modules/intensity_transform/include/opencv2/intensity_transform.hpp'.
and the question is why a file that looks to be in what I'd guess is ${S}:
/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/opencv/4.5.2-
r0/contrib/modules/intensity_transform/include/opencv2/intensity_transform.hpp
was created under pseudo context. Does the recipe give any clue about that?
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53543): https://lists.yoctoproject.org/g/yocto/message/53543
Mute This Topic: https://lists.yoctoproject.org/mt/82884027/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] meta-selinux issues. Depending on what I put in my local.conf, I get boot loops or can't log in.
On Sat, 2021-05-15 at 22:15 -0400, Brian Hutchinson wrote: > > > On Fri, May 14, 2021 at 12:35 AM Yi Zhao wrote: > > > > On 5/14/21 9:40 AM, Brian Hutchinson wrote: > > > > > Hi, > > > > > > Pretty new to selinux. I've worked through a lot of issues to get this > > > far but am stumped at the moment > > > so any pointers, clues are appreciated. > > > > > > I'm trying to add selinux to my custom image. After running into > > > problems, I decided it was best to > > > start with building core-image-selinux for my NXP imx8mm-evk board as a > > > reference for getting my custom > > > image to work. > > > > > > I'm using fscl-community-bsp meta-freescale Dunfell release which is > > > building a 5.4.114 kernel. > > > > > > My first issues were getting kernel config options right (.config > > > attached). I kept booting my rootfs > > > and sestatus would result in selinux not being enabled. > > > > > > After getting kernel config somewhat worked out, then I started getting > > > either boot loops or locked out. > > > > > > I'll stay focused on my core-image-selinux image as hopefully if I can > > > get it working it will help me > > > get my custom image working too. > > > > > > Here is my last iteration of my local.conf that results in me not being > > > able to log in. With core- > > > image-selinux image, it freezes before it gets to login prompt. On my > > > custom image, I get log in prompt > > > but when I try to log in a root I get audit messages and dropped back to > > > login prompt. > > > > > > local.conf for core-image-selinux: > > > > > > MACHINE ??= 'imx8mmevk' > > > DISTRO ?= 'poky' > > > PACKAGE_CLASSES ?= 'package_rpm' > > > EXTRA_IMAGE_FEATURES ?= "debug-tweaks" > > > DISTRO_FEATURES_remove = " sysvinit" > > > DISTRO_FEATURES_append += " acl xattr pam selinux systemd" > > > VIRTUAL-RUNTIME_init_manager = "systemd" > > > DISTRO_FEATURES_BACKFILL_CONSIDERED = "" > > > PREFERRED_PROVIDER_virtual/refpolicy ?= "refpolicy-mls" > > > > You can try refpolicy-mcs or refpolicy-targeted. The mls policy doesn't > > work for systemed on dunfell. > > > > //Yi > > > > Thank you very much for that! I made that change to my core-image-selinux > build and it worked! When it > booted I saw a systemd process take a while to finish, I assume that was the > relable process. And when I > logged in as root, there is a significant delay before being logged in, not > sure what is going on there. > > When I made the same change to my imx8mm-evk core-image-base image with > selinux added, I saw the same > systemd process run but it didn't take quite as long and it made the system > reboot. Once it rebooted I did > get a login prompt but it won't let me login as root. So something is still > miss-configured and still at a > loss as to what to look at next. I know nothing about this but I was surprised you were using busybox login utilities with selinux. I'm not sure if that is well tested or not... Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53525): https://lists.yoctoproject.org/g/yocto/message/53525 Mute This Topic: https://lists.yoctoproject.org/mt/82814907/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [yocto-autobuilder-helper] [PATCH] config.json: Set XZ limits to more reasonable values on autobuilder
The autobuilders have 128GB memory, we don't want them using 50% which is the default, 5% should be enough. Also limit the number of threads down from 48 to something reasonable. This may be partly causing some of our performance issues? Signed-off-by: Richard Purdie --- config.json | 2 ++ 1 file changed, 2 insertions(+) diff --git a/config.json b/config.json index 6533dab..cf62815 100644 --- a/config.json +++ b/config.json @@ -45,6 +45,8 @@ "BB_GENERATE_MIRROR_TARBALLS = '1'", "BB_NUMBER_THREADS = '16'", "PARALLEL_MAKE = '-j 16'", +"XZ_MEMLIMIT = '5%'", +"XZ_THREADS = '8'", "BB_TASK_NICE_LEVEL = '5'", "BB_TASK_NICE_LEVEL_task-testimage = '0'", "BB_TASK_IONICE_LEVEL = '2.7'", -- 2.30.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53524): https://lists.yoctoproject.org/g/yocto/message/53524 Mute This Topic: https://lists.yoctoproject.org/mt/82862130/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] FW: Yocto Distro Testing Plan
On Wed, 2021-05-12 at 18:48 +, Kraft, George wrote: > Could someone point me to a wiki on how yocto testing/QA/conformance is done? > The Distro Testing Plan wiki seems outdated, and my inquiry to Jose bounced. The wiki is a bit out of date, sorry. We have been working on documenting our testing in a manual: http://docs.yoctoproject.org/test-manual/index.html Short summary is you can see builds here: https://autobuilder.yoctoproject.org/typhoon/#/ and an example release test report: http://downloads.yoctoproject.org/releases/yocto/yocto-3.3/testreport.txt Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53488): https://lists.yoctoproject.org/g/yocto/message/53488 Mute This Topic: https://lists.yoctoproject.org/mt/82782535/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] esdk issue using hardknott sources #yocto
On Mon, 2021-05-10 at 21:13 -0700, sateesh m wrote: > Hi Guys, > > I have successfully built core-image-base image using hardknott > sources. I am trying to build > sdk & populate_sdk_ext. I have built successfully.but when I running > ./oecore-x86_64-riscv64-toolchain-ext- > nodistro.0.sh > > I am facing issue xorgproto write config failed. > > Can anybody known this issue please help me to solve. It looks like you're using OE-Core and nodistro and we generally test the eSDK with poky. It also looks like you're using rm_work and we do not test that with eSDK on the autobuilder. For some reason the generated task hashes in the eSDK are not matching the hashes generated by the previous build. I mention the above as those are two differences I can see between what you're doing and what we test. I don't know what is causing those differences though. We are aware this part of the build is rather hard to debug unfortunately. We've not managed to find a way to make this easier as yet. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53449): https://lists.yoctoproject.org/g/yocto/message/53449 Mute This Topic: https://lists.yoctoproject.org/mt/82739046/21656 Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [Openembedded-architecture] Open Source Maintainers - An open letter/request
On Mon, 2021-05-10 at 13:52 -0700, akuster808 wrote: > > On 5/10/21 8:14 AM, Richard Purdie wrote: > > I appreciate these are difficult times, both for individuals and for > > businesses. I'd like to conclude by thanking everyone who does participate > > and contribute. Whilst I do want/need to highlight the above (and have been > > asked to do so that people have something they can point people at), the > > project is proving to be successful, going to interesting places and making > > things possible we can all be proud of! > Thanks for summarizing all this. > > So is the ask to forward this within the one's Employer? I think people will know what is appropriate in their own circumstances. There was an ask that some of these things be "documented" and I'm trying to do that as I think some of the things here are often overlooked or misunderstood. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53440): https://lists.yoctoproject.org/g/yocto/message/53440 Mute This Topic: https://lists.yoctoproject.org/mt/82730738/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] Open Source Maintainers - An open letter/request
TLDR: The project is seen as mature, employers don't prioritise maintaining things and we're struggling for maintainers and help with day to day work Open source projects survive, not just through development work and contributions of new features but through a whole load of "unglamorous" day to day "admin" work. This may be tracking down a regression, triaging failing builds, making a release of a component, reviewing a patch, documenting something or many other activities. I love the fact we have active contributions, particularly for new features but we are continuing to struggle in many of the other areas above. I am extrememly grateful for the help we do receive with these tasks! As a project we have automated an absolute ton of things, we can test changes in ways we could only dream of a few years ago but maintaining this automation, tracking down regressions and ensuring it all stays working does have a cost. I am worried, not just about the core of the project, but the wider layer ecosystem since "layer maintainer" isn't seen as a particularly interesting career enabling focus by employers and it seems a lot of this work isn't being recognised. Internal business pressures are often continually being prioritised over this. The YP+OE ecosystem is becoming more mature and this means we have our experienced developers being pulled away to new things and few people are replacing them so it feels like we're seeing a gradual skills drain/fade. There are a few things companies can do to help: a) Publicly acknowledge you use the project. I'm often asked where the project is being used but I find it hard to point at companies using it, or products developed with it. It does help to be able to point at real users rather than theoretical scenarios. We *know* it is used in some interesting places but many won't let us say that publicly. https://wiki.yoctoproject.org/wiki/Project_Users b) Embrace employee's Open Source contributions, code and otherwise If companies can find ways to recognise the value of having open source experts/leaders working for them from a career development and reward perspective, that would encourage people to do the important work needed c) Consider Yocto Project membership https://www.yoctoproject.org/ecosystem/members/ https://www.yoctoproject.org/join/ We're finding that some infrastructure and roles need to be centrally funded as the work is important but no one company is willing to commit people to it. We're only able to to this through project membership which supports things like the autobuilder, LTS, our build triage process and my own role. d) Support employees in spending some time on open source projects I hear quite often that employees get XX% time to spend on open source projects. I also hear they get pulled onto mission critical product deliverables and can't prioritise that other project work. Finding ways to ensure employees can spend time on open source projects including management support would help a lot. e) Transition roles If someone has a key role in a project but is moving to new things, help them find a replacement and allow them time to train/transition to that new person. Some companies do this really well, I'd call out NI and opkg maintainership as a particularly good exmaple. I appreciate these are difficult times, both for individuals and for businesses. I'd like to conclude by thanking everyone who does participate and contribute. Whilst I do want/need to highlight the above (and have been asked to do so that people have something they can point people at), the project is proving to be successful, going to interesting places and making things possible we can all be proud of! Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53438): https://lists.yoctoproject.org/g/yocto/message/53438 Mute This Topic: https://lists.yoctoproject.org/mt/82722441/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] KeyError: 'getpwuid(): uid not found: 1000' in do_package phase
On Fri, 2021-05-07 at 10:10 +0300, Thomas Hill via lists.yoctoproject.org wrote:
> On Thu, 6 May 2021, 13:44 Martin Jansa wrote:
> > On Thu, May 6, 2021 at 10:57 AM Thomas Hill via lists.yoctoproject.org
> > wrote:
> > > Hi Martin!
>
> > > > On Mon, Nov 16, 2020 at 02:28 PM, Martin Jansa wrote:
> > > > https://github.com/webOS-ports/meta-webos-ports/commit/9fd17a67cdbed92df13a14b002a189b4c6c2d442
>
> > > > is an example where it triggers this error, but doesn't trigger the
> > > > more common host-user-contaminated QA error (unless you happened to use
> > > > UID 1001 on host for the user running bitbake).
> > I have here a similar problem with one of my own packages. It happens that
> > my bitbake user uses UID 1001. Do you have more information why this is a
> > problem? Should it be enough to change the UID to 1002 to get everything
> > running?
>
> > No, you should chown the files to be owned by the expected user which
> > exists in the image (probably root like in my commit). Changing the UID of
> > the user on host is very bad work around (as it will fail for the next
> > person building the same image with host user 1001.
>
> Ok. Thanks. I can confirm that the change of the bitbake users UID to
> did not solve the issue.
> I will open a new thread because I don't see why this fails. I use oe_runmake
> in my do_install function and got the impression that oe_runmake should take
> care of this via fakeroot.
When you install files during do_install, you need to be clear about who
you want to own the end result.
If you do something like "touch ${D}/x", the it will be owned by the default
user which in a fakeroot context under pseudo is root.
If however you cp a file to ${D}/x, it would depend what you told cp
to do about ownership. If the original file was owned by user 1001, it
may try and preserve that.
We don't know what your code is doing in do_install but its almost certainly
not setting the file ownership correctly.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53418): https://lists.yoctoproject.org/g/yocto/message/53418
Mute This Topic: https://lists.yoctoproject.org/mt/78301741/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] Next Yocto Project LTS - April 2022
I'm pleased to be able to announce that the project is planning to have the April 2022 release next year be our next LTS release. This fits in with our original announced plan of 2 year cycles and recognises that the LTS has been well received by members and our community. It also aligns well with LTS releases of other projects meaning we have "co-travellers". The current dunfell LTS would be due to end at that time. There has been discussion about extending it beyond the currently planned timeframe but no agreement/decision has been made on the extra finance that would require at this time. There is also some concern about the potential pressure on layer maintainers in wider ecosystem which we plan to investigate further. By confirming this now, we're hoping to give people a chance to align strategies and plan for feature development to land into the LTS. There is a clear need for any new/experimental changes to be planned/developed now in order to ensure they're ready and stabilised for the LTS. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53411): https://lists.yoctoproject.org/g/yocto/message/53411 Mute This Topic: https://lists.yoctoproject.org/mt/82627563/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH] config.json: Remove -j option for reproducibility as live output is useful
The -j option has the side effect that the output is cached. For a long running
single threaded target, the live output is more useful so switch to it.
Signed-off-by: Richard Purdie
---
config.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/config.json b/config.json
index 3e12d3f..6533dab 100644
--- a/config.json
+++ b/config.json
@@ -191,7 +191,7 @@
"SDKMACHINE" : "x86_64",
"step1" : {
"shortname" : "Reproducible Selftest",
-"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc;
OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail/ DISPLAY=:1
oe-selftest -r reproducible -j 1"],
+"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc;
OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail/ DISPLAY=:1
oe-selftest -r reproducible"],
"ADDLAYER" : ["${BUILDDIR}/../meta-selftest"]
}
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53410): https://lists.yoctoproject.org/g/yocto/message/53410
Mute This Topic: https://lists.yoctoproject.org/mt/82627420/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Hardknott - pseudo excluded from intercept_scripts
On Wed, 2021-05-05 at 00:56 -0700, Chuck Wolber wrote:
> The following code is an effective workaround. It must be added after the
> core-image is inherited.
>
> python () {
> pseudo_ignore_paths = d.getVar('PSEUDO_IGNORE_PATHS')
> result = ','.join([x for x in pseudo_ignore_paths.split(',') if
> "intercept_scripts" not in x])
> d.setVar('PSEUDO_IGNORE_PATHS', result)
> }
>
> ..Ch:W..
>
> On Tue, May 4, 2021 at 8:53 PM Chuck Wolber via lists.yoctoproject.org <
> chuckwolber=gmail@lists.yoctoproject.org> wrote:
> >
> > I was attempting an image build with Yocto Hardknott, and I ran into a
> > chown problem during do_rootfs(). I
> > traced it down to ${WORKDIR}/intercept_scripts showing up in the
> > PSEUDO_IGNORE_PATHS environment variable.
> >
> > This commit made the change:
> > https://git.openembedded.org/openembedded-core/commit/meta/classes/image.bbclass?id=9463be2292b942a1072eea1b9644e55aadb9
> >
> > I continued down the rabbit hole until I got here:
> > https://git.openembedded.org/openembedded-core/tree/meta/lib/oe/package_manager/__init__.py#n173
> >
> > Line 192 specifically is the smoking gun. The files are being copied from
> > poky/scripts/postinst-intercepts
> > into the ${WORKDIR}/intercept_scripts directory and immediately failing
> > when the copyFile utility attempts
> > to do a chown.
> >
> > Is there any logical explanation for this? Is this a bug or am I doing
> > something wrong? Is there a
> > workaround?
This should be fixed in master, the issue was triggered by a checkout
owned by root/root:
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=eff192abe2ee43ebf981bafbb7fca8602ebdcf0c
Steve/Anuj: We'll likely want to backport that one.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53408): https://lists.yoctoproject.org/g/yocto/message/53408
Mute This Topic: https://lists.yoctoproject.org/mt/82596907/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] SSH_AUTH_SOCK unavailable when pulling modules #golang
On Mon, 2021-05-03 at 11:25 -0700, Sven via lists.yoctoproject.org wrote:
Hi,
I have put together a recipe inheriting from go-mod. This project depends on
> out-of-repo modules that sit in private repos. As long as the SSH key
> required
> to pull the requirements is present as a file (under $HOME/.ssh), everything
> works fine. However, as soon as the SSH credentials are only available via
> agent and $SSH_AUTH_SOCK, the do_compile step fails. I have traced this down
> to the fact that the $SSH_AUTH_SOCK environment variable is not available to
> do_compile which is when the requirements are pulled. This is the sort of
> error
> message I get:
ERROR: mypackage-git-r0 do_compile: Execution of
'[...]/mypackage/git-r0/temp/run.do_compile.20076'
> failed with exit code 1:
# cd .; git ls-remote https://bitbucket.org/myorg/some-requirement
Permission denied (publickey).
fatal: Could not read from remote repository.
Note, that the do_fetch step succeeds in pulling the actual repo. I tried
fixing
> the problem by wrapping the do_compile function and providing $SSH_AUTH_SOCK
> from
> the original environment:
def origenv(d, var):
return d.getVar("BB_ORIGENV", False).getVar(var, False)
do_compile() {
if [ -n "${@origenv(d, 'SSH_AUTH_SOCK') or ''}" ]; then
export SSH_AUTH_SOCK="${@origenv(d, 'SSH_AUTH_SOCK')}"
fi
go_do_compile
}
This allows the do_compile step (and all subsequent steps) to finish
successfully.
> However, that way, I get a bunch of errors like this (cleansstate does not
> help):
ERROR: When reparsing [...]/mypackage_git.bb:do_compile, the basehash value
> changed from eb51e4ec321c723587cec03bb9b33b94ee43e0b0939eb43b52824e3d5cfebec2
> to 2bb034f43856917d6454a56b32946b1c68cf7f286b20fd7a7eaf1bfd2a92d34f. The
> metadata
> is not deterministic and this needs to be fixed.
ERROR: The following commands may help:
ERROR: $ bitbake mypackage -cdo_compile -Snone
ERROR: Then:
ERROR: $ bitbake mypackage -cdo_compile -Sprintdiff
Neither command helps to fix this. What can I do? I'm on poky
yocto-3.1.5-18-gbb7747497a.
You can probably 'fix' that with:
do_compile[vardepsexclude] += "SSH_AUTH_SOCK"
however you really shouldn't be accessing the network in a compile task.
That is a wider go issue :(.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53399): https://lists.yoctoproject.org/g/yocto/message/53399
Mute This Topic: https://lists.yoctoproject.org/mt/82558905/21656
Mute #golang:https://lists.yoctoproject.org/g/yocto/mutehashtag/golang
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [yocto] Yocto Project Status WW18`21
On Tue, 2021-05-04 at 18:38 +0200, Alexander Kanavin wrote: > On Tue, 4 May 2021 at 16:46, Stephen Jolley wrote: > > We are pleased to announce that our April 2022 release (potentially 3.5) > > will > > be the next LTS as per our original two year schedule. If there are > > features > > desired in the next LTS, now is the time to get them submitted and > > stabilized > > ready. > > > > What will happen to the current LTS at that point? Will support be cut off, > will there be a transition window, or is it currently undefined? We have discussed extending it but we currently only have the funding for the originally planned 2 years. Discussions are continuing but since we do all agree that the next LTS will start then, we decided to at least let people plan against that. Unless funding/support is secured, dunfell would move to community support if anyone were willing to step up, or become EOL and replaced by the new LTS. There would likely be some period of overlap of a few months to transition. There is also concern about pressuring wider community layers for longer support cycles which is something we need to think about. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53381): https://lists.yoctoproject.org/g/yocto/message/53381 Mute This Topic: https://lists.yoctoproject.org/mt/82591732/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [yocto-autobuilder2] [PATCH] config/schedulers: Add check-layer-nightly
Add a new target to run layer checks every 24 hours on various layers we don't
test as part of the standard test runs.
Signed-off-by: Richard Purdie
---
config.py | 2 ++
schedulers.py | 5 +
2 files changed, 7 insertions(+)
diff --git a/config.py b/config.py
index 54ec9ce8..82076cd3 100644
--- a/config.py
+++ b/config.py
@@ -23,6 +23,7 @@ buildertorepos = {
"qemuarm-oecore": ["oecore", "bitbake"],
"checkuri": ["poky"],
"check-layer": ["poky", "meta-mingw", "meta-gplv2"],
+"check-layer-nightly": ["poky", "meta-agl", "meta-arm", "meta-aws",
"meta-intel", "meta-openembedded", "meta-virtualization"],
"docs": ["yocto-docs", "bitbake"],
"default": ["poky"]
}
@@ -110,6 +111,7 @@ builders_others = [
"qemuarm-armhost",
"meta-agl-core",
"meta-aws",
+"check-layer-nightly",
"auh"
]
diff --git a/schedulers.py b/schedulers.py
index 9d81806b..8b166e0b 100644
--- a/schedulers.py
+++ b/schedulers.py
@@ -352,6 +352,11 @@ schedulers.append(sched.Nightly(name='nightly-quick',
branch='master', propertie
schedulers.append(sched.Nightly(name='nightly-full', branch='master',
properties=parent_default_props('a-full'),
builderNames=['a-full'], hour=1, minute=0, dayOfWeek=6))
+# Run check-layer-nightly each day
+schedulers.append(sched.Nightly(name='nightly-check-layer', branch='master',
properties=parent_default_props('check-layer-nightly'),
+ builderNames=['check-layer-nightly'], hour=0, minute=0))
+
+
# Run the build performance tests at 3am, 9am, 3pm and 9pm
schedulers.append(sched.Nightly(name='nightly-buildperf-ubuntu1604',
branch='master', properties=parent_default_props('buildperf-ubuntu1604'),
builderNames=['buildperf-ubuntu1604'], hour=[3,9,15,21],
minute=0))
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53221): https://lists.yoctoproject.org/g/yocto/message/53221
Mute This Topic: https://lists.yoctoproject.org/mt/82285894/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-gplv2] [PATCH] conf/distro: Add removal of btrfs-tools from util-linux ptest depends
btrfs-tools has changed to LGPL-3.1 so to allow util-linux to build,
remove the dependency from its ptest package. This may regress some
ptests but keeps the gplv2 layer working.
Signed-off-by: Richard Purdie
---
conf/distro/include/disable-gplv3.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/conf/distro/include/disable-gplv3.inc
b/conf/distro/include/disable-gplv3.inc
index bded378..3285543 100644
--- a/conf/distro/include/disable-gplv3.inc
+++ b/conf/distro/include/disable-gplv3.inc
@@ -1,3 +1,4 @@
INCOMPATIBLE_LICENSE = '*GPLv3*'
WARN_QA_remove = 'incompatible-license'
RDEPENDS_${PN}-ptest_remove_pn-glib-2.0 = "python3-dbusmock"
+RDEPENDS_${PN}-ptest_remove_pn-util-linux = "btrfs-tools"
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53173): https://lists.yoctoproject.org/g/yocto/message/53173
Mute This Topic: https://lists.yoctoproject.org/mt/82219423/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] bitbake controlling memory use
On Sun, 2021-04-18 at 00:17 +0200, Gmane Admin wrote: > Hi, > Op 14-04-2021 om 06:59 schreef Richard Purdie: > > On Tue, 2021-04-13 at 21:14 -0400, Randy MacLeod wrote: > > > On 2021-04-11 12:19 p.m., Alexander Kanavin wrote: > > > > make already has -l option for limiting new instances if load average is > > > > too high, so it's only natural to add a RAM limiter too. > > > > > > > > -l [N], --load-average[=N], --max-load[=N] > > > > Don't start multiple jobs unless load is > > > > below N. > > > > > > > > In any case, patches welcome :) > > > > > > During today's Yocto technical call (1), > > > we talked about approaches to limiting the system load and avoiding > > > swap and/or OOM events. Here's what (little!) i recall from the > > > discussion, 9 busy hours later. > > > > > > In the short run, instead of independently maintaining changes to > > > configurations to limit parallelism or xz memory usage, etc, we > > > could develop an optional common include file where such limits > > > are shared across the community. > > I tried PARALLEL_MAKE_nodejs = "-j 1" from local.conf but that didn't work. It would need to be: PARALLEL_MAKE_pn-nodejs = "-j 1" > So I watched it run for a while. It compiles with g++ and as at about > 0.5GB per thread, which is OK. In the end it does ld taking 4GB and it > tries to do 4 in parallel. And then swapping becomes so heavy the > desktop becomes unresponsive. Like I mentioned before ssh from another > machine allows me to STOP one of them, allowing the remaining to > complete. And then CONT the last one. > > I worked around it now, by creating a bbappend for nodejs with only > PARALLEL_MAKE = "-j 2" > > If that works, the override above should also work. You do need the "pn-" prefix to the recipe name though. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53159): https://lists.yoctoproject.org/g/yocto/message/53159 Mute This Topic: https://lists.yoctoproject.org/mt/82015730/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [PATCH yocto-autobuilder-helper 2/4] config.json: collect data by default
On Fri, 2021-04-16 at 09:28 +0100, Richard Purdie via lists.yoctoproject.org
wrote:
> On Tue, 2021-04-13 at 13:02 -0400, sakib.sa...@windriver.com wrote:
> > add the variables required to collect data to "defaults"
> > so that data is collected on all builds.
> >
> > Signed-off-by: Sakib Sajal
> > Signed-off-by: Randy MacLeod
> > ---
> > config.json | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/config.json b/config.json
> > index c43d231..cd82047 100644
> > --- a/config.json
> > +++ b/config.json
> > @@ -55,7 +55,10 @@
> > "SDK_INCLUDE_TOOLCHAIN = '1'",
> > "BB_DISKMON_DIRS = 'STOPTASKS,${TMPDIR},1G,100K
> > STOPTASKS,${DL_DIR},1G STOPTASKS,${SSTATE_DIR},1G STOPTASKS,/tmp,100M,100K
> > ABORT,${TMPDIR},100M,1K ABORT,${DL_DIR},100M ABORT,${SSTATE_DIR},100M
> > ABORT,/tmp,10M,1K'",
> > "BB_HASHSERVE = 'typhoon.yocto.io:8686'",
> > -"RUNQEMU_TMPFS_DIR = '/home/pokybuild/tmp'"
> > +"RUNQEMU_TMPFS_DIR = '/home/pokybuild/tmp'",
> > +"BB_HEARTBEAT_EVENT = '10'",
> > +"BB_LOG_HOST_STAT_ON_INTERVAL = '1'",
> > +"BB_LOG_HOST_STAT_CMDS = 'oe-time-dd-test.sh 100'"
> > ]
> > },
> > "templates" : {
>
> I merged 2-4 of this series, unfortunately this resulted in a few issues
> overnight:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/85/builds/1393
>
> which is due to the non-executable script which there is a patch for, it just
> wasn't in master due to the release. I've fixed that by merging the patches.
>
> The bigger issue is the performance metrics which this broke:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/91/builds/4427
> https://autobuilder.yoctoproject.org/typhoon/#/builders/92/builds/4453
>
> We're going to need to disable these events on the performance metrics
> targets...
There is also another issue as BB_HEARTBEAT_EVENT defaults to 1, the change to
10
changes the default timings for buildstats and other pieces of code. In
particular
I suspect this is breaking:
https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/1993
and again in:
https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/2014
in the disk monitoring selftest...
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53154): https://lists.yoctoproject.org/g/yocto/message/53154
Mute This Topic: https://lists.yoctoproject.org/mt/82074297/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [PATCH yocto-autobuilder-helper 2/4] config.json: collect data by default
On Tue, 2021-04-13 at 13:02 -0400, sakib.sa...@windriver.com wrote:
> add the variables required to collect data to "defaults"
> so that data is collected on all builds.
>
> Signed-off-by: Sakib Sajal
> Signed-off-by: Randy MacLeod
> ---
> config.json | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/config.json b/config.json
> index c43d231..cd82047 100644
> --- a/config.json
> +++ b/config.json
> @@ -55,7 +55,10 @@
> "SDK_INCLUDE_TOOLCHAIN = '1'",
> "BB_DISKMON_DIRS = 'STOPTASKS,${TMPDIR},1G,100K
> STOPTASKS,${DL_DIR},1G STOPTASKS,${SSTATE_DIR},1G STOPTASKS,/tmp,100M,100K
> ABORT,${TMPDIR},100M,1K ABORT,${DL_DIR},100M ABORT,${SSTATE_DIR},100M
> ABORT,/tmp,10M,1K'",
> "BB_HASHSERVE = 'typhoon.yocto.io:8686'",
> -"RUNQEMU_TMPFS_DIR = '/home/pokybuild/tmp'"
> +"RUNQEMU_TMPFS_DIR = '/home/pokybuild/tmp'",
> +"BB_HEARTBEAT_EVENT = '10'",
> +"BB_LOG_HOST_STAT_ON_INTERVAL = '1'",
> +"BB_LOG_HOST_STAT_CMDS = 'oe-time-dd-test.sh 100'"
> ]
> },
> "templates" : {
I merged 2-4 of this series, unfortunately this resulted in a few issues
overnight:
https://autobuilder.yoctoproject.org/typhoon/#/builders/85/builds/1393
which is due to the non-executable script which there is a patch for, it just
wasn't in master due to the release. I've fixed that by merging the patches.
The bigger issue is the performance metrics which this broke:
https://autobuilder.yoctoproject.org/typhoon/#/builders/91/builds/4427
https://autobuilder.yoctoproject.org/typhoon/#/builders/92/builds/4453
We're going to need to disable these events on the performance metrics
targets...
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53153): https://lists.yoctoproject.org/g/yocto/message/53153
Mute This Topic: https://lists.yoctoproject.org/mt/82074297/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [PATCH yocto-autobuilder-helper 1/4] config.json: add "collect-data" template
On Thu, 2021-04-15 at 11:31 -0400, Sakib Sajal wrote:
> On 2021-04-15 9:52 a.m., Richard Purdie wrote:
> > [Please note: This e-mail is from an EXTERNAL e-mail address]
> >
> > On Tue, 2021-04-13 at 13:02 -0400, sakib.sa...@windriver.com wrote:
> > > collect-data template can run arbitrary commands/scripts
> > > on a regular basis and logs the output in a file.
> > >
> > > See oe-core for more details:
> > > edb7098e9e buildstats.bbclass: add functionality to collect build
> > > system stats
> > >
> > > Signed-off-by: Sakib Sajal
> > > Signed-off-by: Randy MacLeod
> > > ---
> > > config.json | 7 +++
> > > 1 file changed, 7 insertions(+)
> > >
> > > diff --git a/config.json b/config.json
> > > index 5bfa240..c43d231 100644
> > > --- a/config.json
> > > +++ b/config.json
> > > @@ -87,6 +87,13 @@
> > > "SANITYTARGETS" : "core-image-full-cmdline:do_testimage
> > > core-image-sato:do_testimage core-image-sato-sdk:do_testimage"
> > > }
> > > },
> > > + "collect-data" : {
> > > +"extravars" : [
> > > +"BB_HEARTBEAT_EVENT = '10'",
> > > +"BB_LOG_HOST_STAT_ON_INTERVAL = '1'",
> > > +"BB_LOG_HOST_STAT_CMDS = 'oe-time-dd-test.sh 100'"
> > > +]
> > > +},
> > Is the template used anywhere? I can't remember if we support nesting
> > templates in which
> > case this is useful, or not?
> >
> > Cheers,
> >
> > Richard
>
> The template is not used anywhere, yet, the initial patchset enables the
> data collection by default.
>
> I have left the template in case the data collection is removed from
> defaults and need to be used on a case by case basis.
>
> I am not entirely sure if nesting templates work. I have not seen any
> examples of it, neither did i try it myself. If nesting does work, the
> template should be useful.
I had a quick look at the code and sadly, it doesn't appear I implemented
nesting so this wouldn't be that useful as things stand.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53147): https://lists.yoctoproject.org/g/yocto/message/53147
Mute This Topic: https://lists.yoctoproject.org/mt/82074296/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [PATCH yocto-autobuilder-helper 1/4] config.json: add "collect-data" template
On Tue, 2021-04-13 at 13:02 -0400, sakib.sa...@windriver.com wrote:
> collect-data template can run arbitrary commands/scripts
> on a regular basis and logs the output in a file.
>
> See oe-core for more details:
> edb7098e9e buildstats.bbclass: add functionality to collect build system
> stats
>
> Signed-off-by: Sakib Sajal
> Signed-off-by: Randy MacLeod
> ---
> config.json | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/config.json b/config.json
> index 5bfa240..c43d231 100644
> --- a/config.json
> +++ b/config.json
> @@ -87,6 +87,13 @@
> "SANITYTARGETS" : "core-image-full-cmdline:do_testimage
> core-image-sato:do_testimage core-image-sato-sdk:do_testimage"
> }
> },
> + "collect-data" : {
> +"extravars" : [
> +"BB_HEARTBEAT_EVENT = '10'",
> +"BB_LOG_HOST_STAT_ON_INTERVAL = '1'",
> +"BB_LOG_HOST_STAT_CMDS = 'oe-time-dd-test.sh 100'"
> +]
> +},
Is the template used anywhere? I can't remember if we support nesting templates
in which
case this is useful, or not?
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53145): https://lists.yoctoproject.org/g/yocto/message/53145
Mute This Topic: https://lists.yoctoproject.org/mt/82074296/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] bitbake controlling memory use
On Tue, 2021-04-13 at 21:14 -0400, Randy MacLeod wrote: > On 2021-04-11 12:19 p.m., Alexander Kanavin wrote: > > make already has -l option for limiting new instances if load average is > > too high, so it's only natural to add a RAM limiter too. > > > > -l [N], --load-average[=N], --max-load[=N] > > Don't start multiple jobs unless load is > > below N. > > > > In any case, patches welcome :) > > During today's Yocto technical call (1), > we talked about approaches to limiting the system load and avoiding > swap and/or OOM events. Here's what (little!) i recall from the > discussion, 9 busy hours later. > > In the short run, instead of independently maintaining changes to > configurations to limit parallelism or xz memory usage, etc, we > could develop an optional common include file where such limits > are shared across the community. > > In the longer run, changes to how bitbake schedules work may be needed. > > Richard says that there was a make/build server idea and maybe even a > patch from a while ago. It may be in one of his poky-contrib branches. > I took a few minutes to look but nothing popped up. A set of keywords to > search for might help me find it. http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wipqueue4&id=d66a327fb6189db5de8bc489859235dcba306237 Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53123): https://lists.yoctoproject.org/g/yocto/message/53123 Mute This Topic: https://lists.yoctoproject.org/mt/82015730/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [yocto-autobuilder2] [PATCH] config: Add meta-aws to base configuration
On Tue, 2021-04-13 at 14:59 +0100, Richard Purdie via lists.yoctoproject.org wrote: > Signed-off-by: Richard Purdie > --- > bsp-addition-example.patch | 54 -- > config.py | 3 +++ > 2 files changed, 3 insertions(+), 54 deletions(-) > delete mode 100644 bsp-addition-example.patch > > diff --git a/bsp-addition-example.patch b/bsp-addition-example.patch > deleted file mode 100644 > index 7f92789d.. > --- a/bsp-addition-example.patch > +++ /dev/null Not sure what happened with the file deletion but I'll fix that. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53097): https://lists.yoctoproject.org/g/yocto/message/53097 Mute This Topic: https://lists.yoctoproject.org/mt/82065254/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [yocto-autobuilder2] [PATCH] config: Add meta-aws to base configuration
Signed-off-by: Richard Purdie
---
bsp-addition-example.patch | 54 --
config.py | 3 +++
2 files changed, 3 insertions(+), 54 deletions(-)
delete mode 100644 bsp-addition-example.patch
diff --git a/bsp-addition-example.patch b/bsp-addition-example.patch
deleted file mode 100644
index 7f92789d..
--- a/bsp-addition-example.patch
+++ /dev/null
@@ -1,54 +0,0 @@
-From d5fb6c086c18722532333c8af1e19b42b9ffb138 Mon Sep 17 00:00:00 2001
-From: Aaron Chan
-Date: Tue, 28 Aug 2018 10:49:13 +0800
-Subject: [PATCH] config.py: Add new job category with suffix bsp
-
-Add new support on Open Source Automated Hardware Tests on BSP test
-cases. New job category is define with builder name standard as
-"nightly--bsp" where Yocto Project supports architecutures on
-hardware platforms of x86, x86-64, arm, arm64, mips, mips64, pcc.
-
-Add initial support on x86-64 BSP hardware tests and included meta
-layers needed to run QA test cases on these platforms.
-Community to adopt and add support to autobuilder job config to
-support future BSP testing and validation on their architecture.
-
-Signed-off-by: Aaron Chan
- config.py | 9 +++--
- 1 file changed, 7 insertions(+), 2 deletions(-)
-
-diff --git a/config.py b/config.py
-index 2568768..10f740d 100644
a/config.py
-+++ b/config.py
-@@ -11,6 +11,7 @@
- "nightly-oecore": ["oecore", "bitbake"],
- "nightly-checkuri": ["poky", "meta-qt4", "meta-qt3"],
- "nightly-check-layer": ["poky", "meta-mingw", "meta-gplv2"],
-+"nightly-x86-64-bsp": ["poky", "meta-intel", "meta-openembedded",
"meta-security", "meta-ros", "meta-browser"],
- "default": ["poky"]
- }
-
-@@ -32,7 +33,11 @@
- "meta-qt4": ["git://git.yoctoproject.org/meta-qt4", "master"],
- "meta-qt3": ["git://git.yoctoproject.org/meta-qt3", "master"],
- "meta-mingw": ["git://git.yoctoproject.org/meta-mingw", "master"],
--"meta-gplv2": ["git://git.yoctoproject.org/meta-gplv2", "master"]
-+"meta-gplv2": ["git://git.yoctoproject.org/meta-gplv2", "master"],
-+"meta-security": ["git://git.yoctoproject.org/meta-security", "master"],
-+"meta-openembedded": ["git://git.openembedded.org/meta-openembedded",
"master"],
-+"meta-ros": ["git://github.com/bmwcarit/meta-ros", "master"],
-+"meta-browser": ["git://github.com/OSSystems/meta-browser", "master"]
- }
-
- trigger_builders_wait = [
-@@ -40,7 +45,7 @@
- "nightly-mips", "nightly-mips-lsb", "nightly-mips64",
- "nightly-multilib", "nightly-x32",
- "nightly-ppc", "nightly-ppc-lsb",
--"nightly-x86-64", "nightly-x86-64-lsb",
-+"nightly-x86-64", "nightly-x86-64-lsb", "nightly-x86-64-bsp",
- "nightly-x86", "nightly-x86-lsb",
- "nightly-packagemanagers",
- "nightly-rpm-non-rpm", "nightly-deb-non-deb",
diff --git a/config.py b/config.py
index 903cb4b8..54ec9ce8 100644
--- a/config.py
+++ b/config.py
@@ -19,6 +19,7 @@ buildertorepos = {
"meta-intel": ["poky", "meta-intel"],
"meta-arm": ["poky", "meta-arm", "meta-kernel"],
"meta-agl-core": ["poky", "meta-agl"],
+"meta-aws": ["poky", "meta-aws", "meta-openembedded"],
"qemuarm-oecore": ["oecore", "bitbake"],
"checkuri": ["poky"],
"check-layer": ["poky", "meta-mingw", "meta-gplv2"],
@@ -40,6 +41,7 @@ repos = {
"meta-intel": ["git://git.yoctoproject.org/meta-intel", "master"],
"meta-arm": ["git://git.yoctoproject.org/meta-arm", "master"],
"meta-agl": ["https://git.automotivelinux.org/AGL/meta-agl";, "next"],
+"meta-aws": ["https://github.com/aws/meta-aws.git";, "master"],
"oecore": ["git://git.openembedded.org/openembedded-core",
"master"],
"bitbake": ["git://git.openembedded.org/bitbake", "master"],
@@ -107,6 +109,7 @@ builders_others = [
"bringup",
"qemuarm-armhost",
"meta-agl-core",
+"meta-aws",
"auh"
]
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53096): https://lists.yoctoproject.org/g/yocto/message/53096
Mute This Topic: https://lists.yoctoproject.org/mt/82065254/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [yocto-autobuilder2] [PATCH] config/schedulers: Add hardknott config for new release
Signed-off-by: Richard Purdie
---
config.py | 1 +
schedulers.py | 14 --
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/config.py b/config.py
index 299f2aa5..903cb4b8 100644
--- a/config.py
+++ b/config.py
@@ -142,6 +142,7 @@ all_workers = workers + workers_bringup + workers_buildperf
+ workers_arm
# Worker filtering for older releases
workers_prev_releases = {
+"hardknott" : ("centos7", "centos8", "debian8", "debian9", "debian10",
"fedora31", "fedora32", "fedora33", "opensuse152", "ubuntu1604", "ubuntu1804",
"ubuntu2004", "perf-"),
"gatesgarth" : ("centos7", "centos8", "debian8", "debian9", "debian10",
"fedora30", "fedora31", "fedora32", "opensuse150", "opensuse151",
"opensuse152", "ubuntu1604", "ubuntu1804", "ubuntu1904", "ubuntu2004", "perf-"),
"dunfell" : ("centos7", "centos8", "debian8", "debian9", "debian10",
"fedora29", "fedora30", "fedora31", "fedora32", "opensuse150", "opensuse151",
"ubuntu1604", "ubuntu1804", "ubuntu1904", "ubuntu2004", "perf-"),
"zeus" : ("centos7", "debian8", "debian9", "debian10", "fedora28",
"fedora29", "fedora30", "opensuse150", "opensuse151", "ubuntu1604",
"ubuntu1804", "ubuntu1904", "perf-"),
diff --git a/schedulers.py b/schedulers.py
index 84792909..b8a73f10 100644
--- a/schedulers.py
+++ b/schedulers.py
@@ -169,7 +169,7 @@ def parent_scheduler(target):
name="branchselector",
default="master",
label="Release Shortcut Selector",
-choices=["master", "master-next", "mut", "gatesgarth", "dunfell",
"zeus", "warrior", "thud", "sumo", "rocko", "pyro", "morty"],
+choices=["master", "master-next", "mut", "hardknott",
"gatesgarth", "dunfell", "zeus", "warrior", "thud", "sumo", "rocko", "pyro",
"morty"],
selectors={
'master': {
'branch': 'master',
@@ -202,6 +202,16 @@ def parent_scheduler(target):
'branch_meta-mingw': 'master',
'branch_oecore': 'master',
},
+ 'hardknott': {
+'branch': 'hardknott',
+'branch_poky': 'hardknott',
+'branch_bitbake': '1.50',
+'branch_meta-arm': 'hardknott',
+'branch_meta-gplv2': 'hardknott',
+'branch_meta-intel': 'hardknott',
+'branch_meta-mingw': 'hardknott',
+'branch_oecore': 'hardknott',
+ },
'gatesgarth': {
'branch': 'gatesgarth',
'branch_poky': 'gatesgarth',
@@ -354,7 +364,7 @@ schedulers.append(sched.Nightly(name='nightly-auh',
branch='master', properties=
# If any of our sphinx docs branches change, trigger a build
schedulers.append(sched.AnyBranchScheduler(name="yocto-docs-changed",
-change_filter=util.ChangeFilter(project=["yocto-docs"],
branch=["master", "master-next", "gatesgarth", "dunfell", "transition"]),
+change_filter=util.ChangeFilter(project=["yocto-docs"],
branch=["master", "master-next", "hardknott", "gatesgarth", "dunfell",
"transition"]),
codebases = ['', 'yocto-docs', 'bitbake'],
treeStableTimer=60,
builderNames=["docs"]))
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53095): https://lists.yoctoproject.org/g/yocto/message/53095
Mute This Topic: https://lists.yoctoproject.org/mt/82065164/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [error-report-web][PATCH] report-error.bbclass: Add layer and bitbake version info to error report
On Fri, 2021-03-26 at 16:04 +0530, Milan Shah wrote: > It seems like patches sent for error-report-web are not much important to the > community as this patch has > not been reviewed/commented on by anyone since 6th January 2021 (more than > 2.5 months). > > Still, I'm sending a reminder one last time for [YOCTO #9700]. > https://lists.yoctoproject.org/g/yocto/message/51891 > > Please review/comment on it so that things can move further. Sorry, that isn't true, they are important and appreciated. We're just struggling to handle everything. The challenge/problem has been that there are much older patches which were half merged and broke things. People have rightly been complaining about those issues and Khem for example has been carrying a patch for 3 years to work arond that problem. I did figure out a fix for that which has now been merged. We also needed to migrate the service from py2 to py3 and deal with a set of patches that had been applied locally that we had been unaware of until very recently but which complicate things. The people who wrote them are no longer around to help with that. The original authors of this code are no longer around, the people who stepped up to try and help also haven't had time so the support/review has struggled. The service is in daily use however so it is important and that is why I'm now trying to unravel and fix things. I do want to get to your patch but you can appreciate that adding it directly on top of an already failing set of changes wouldn't be good for anyone. We are making progress in resolving the issues so I hope to get some kind of better answer to you soon. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52921): https://lists.yoctoproject.org/g/yocto/message/52921 Mute This Topic: https://lists.yoctoproject.org/mt/79474306/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [yocto-autobuilder-helper][dunfell 01/23] scripts: Add runqemu-renice.c for renicing runqemu
On Wed, 2021-03-24 at 14:39 -1000, Steve Sakoman wrote: > From: Richard Purdie > > Signed-off-by: Richard Purdie > (cherry picked from commit 838be1a00c0383b63d1ab60aa991919404b82655) > Signed-off-by: Steve Sakoman > --- > scripts/runqemu-renice.c | 44 > 1 file changed, 44 insertions(+) > create mode 100644 scripts/runqemu-renice.c This is another one which is only relevant to master, it isn't used from the older branches. [Basically the autobuilder has some code which it pulls from the helper but uses it from the master branch, it isn't release specific. This is the janitor, index code and renice offhand, there may be other bits I forget] Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52883): https://lists.yoctoproject.org/g/yocto/message/52883 Mute This Topic: https://lists.yoctoproject.org/mt/81591932/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [yocto-autobuilder-helper][dunfell 07/23] scripts/generate-testresult-index.py: Use bulma css to improve the look of the index
On Wed, 2021-03-24 at 14:39 -1000, Steve Sakoman wrote: > From: Richard Purdie > > Signed-off-by: Richard Purdie > (cherry picked from commit 4b8eab92ee1f68ec8cd680c62e40b17006fa6efc) > Signed-off-by: Steve Sakoman > --- > scripts/generate-testresult-index.py | 34 > 1 file changed, 24 insertions(+), 10 deletions(-) I'm torn on this and the other generate-testresult-index patches. These are only ever run from the master branch so in the context of dunfell, they don't matter. Equally, they therefore don't hurt anything... Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52880): https://lists.yoctoproject.org/g/yocto/message/52880 Mute This Topic: https://lists.yoctoproject.org/mt/81591940/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [yocto-autobuilder-helper][dunfell 20/23] config.json: Use buildtools tarball on debian9
On Wed, 2021-03-24 at 14:39 -1000, Steve Sakoman wrote:
> From: Richard Purdie
>
> debian9 has python 3.5 which doesn't work with new qemu versions. Its
> the only remaining 3.5 distro so lets move to a minimum of 3.6.
>
> Signed-off-by: Richard Purdie
> (cherry picked from commit 62b3f5553e9c215cf94798ae4694ccb97f6e85dd)
> Signed-off-by: Steve Sakoman
> ---
> config.json | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/config.json b/config.json
> index cedcef7..8eb05e6 100644
> --- a/config.json
> +++ b/config.json
> @@ -1006,6 +1006,7 @@
> },
> "buildtools" : {
> "debian8*" : "${BUILDTOOLS_URL}",
> +"debian9*" : "${BUILDTOOLS_URL}",
> "centos7*" : "${BUILDTOOLS_URL}",
> "perf-centos7*" : "${BUILDTOOLS_URL}"
> }
I suspect you don't need that with dunfell since you're not using such a
new qemu?
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52879): https://lists.yoctoproject.org/g/yocto/message/52879
Mute This Topic: https://lists.yoctoproject.org/mt/81591964/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [error-report-web][PATCH V2] Add local.conf and auto.conf into error details
On Mon, 2021-03-22 at 15:32 +, Richard Purdie via lists.yoctoproject.org wrote: > Sorry about the delay on this, we do really need to get this resolved. > I'm wondering if we should replace the angled brackets test with > https://github.com/mozilla/bleach which would then remove the need > for these workarounds. > > Would you be able to update the patch for the others issues please > and then we can look at this one separately? I just sent out an as yet untested patch which may fix some of the quoting issues by using bleach. I'd still need to add it to the requirements file... Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52800): https://lists.yoctoproject.org/g/yocto/message/52800 Mute This Topic: https://lists.yoctoproject.org/mt/61340472/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [error-report-web] [PATCH] Post/parser: Use bleach to sanitse XSS input
Instead of searching for "<", use bleach to sanity input to avoid
any XSS issues.
Signed-off-by: Richard Purdie
---
Post/parser.py | 26 +-
1 file changed, 9 insertions(+), 17 deletions(-)
diff --git a/Post/parser.py b/Post/parser.py
index f411e02..536e872 100644
--- a/Post/parser.py
+++ b/Post/parser.py
@@ -9,6 +9,7 @@
# Licensed under the MIT license, see COPYING.MIT for details
import json, re
+import bleach
from Post.models import Build, BuildFailure, ErrorType
from django.conf import settings
from django.utils import timezone
@@ -19,21 +20,6 @@ class Parser:
def __init__(self, data):
self.data = data.decode('utf-8')
-# returns true if the values contain '<' char
-# Ignore the failures field (which is an array anyway)
-# Ignore any non-str fields too [YOCTO #14208]
-def contains_tags (self, data):
-for key,val in data.items():
-if key == 'failures':
-continue
-
-if not isinstance(val, str):
-continue
-
-if '<' in val:
-return True
-return False
-
def parse(self, request):
build_fails_logged = []
@@ -42,8 +28,14 @@ class Parser:
except:
return { 'error' : 'Invalid json' }
-if self.contains_tags(jsondata) == True:
-return { 'error' : 'Invalid characters in json' }
+# Bleach data going directly into the database so that
+# displaying in any of the graphing doesn't introduce XSS
+for key,val in jsondata.items():
+if key == 'failures':
+continue
+if not isinstance(val, str):
+continue
+jsondata[key] = bleach.clean(val)
b = Build.objects.create()
try:
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52799): https://lists.yoctoproject.org/g/yocto/message/52799
Mute This Topic: https://lists.yoctoproject.org/mt/81531586/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [error-report-web][PATCH V2] Add local.conf and auto.conf into error details
On Fri, 2020-02-14 at 10:42 +0800, Changqing Li wrote:
> On 12/11/19 1:45 PM, Changqing Li wrote:
> > On 11/13/19 6:36 PM, Paul Eggleton wrote:
> > > Hi Changqing,
> > >
> > > Some comments below.
> > >
> > > On Tuesday, 12 November 2019 9:32:53 PM NZDT
> > > changqing...@windriver.com wrote:
> > > > From: Changqing Li
> > >
> > >
> > > > + {% if detail.BUILD.LOCAL_CONF != "" %}
> > > > + Local Conf:
> > > > + {{
> > > > detail.BUILD.LOCAL_CONF | safe }}
> > > > + {% endif %}
> > > > +
> > > > + {% if detail.BUILD.AUTO_CONF != "" %}
> > > > + Auto Conf:
> > > > + {{
> > > > detail.BUILD.AUTO_CONF | safe }}
> > > > + {% endif %}
> > > We cannot use the safe filter here - doing so could open up an XSS
> > > vulnerability, since anyone can upload anything to the error-report
> > > application and the content could include links or other malicious
> > > HTML data. We should allow it to be auto-escaped. Is there a
> > > particular issue you were using this to solve?
> >
> > This is for resolve a problem when there is angle brackets in
> > local.conf/auto.conf.
> >
> > I have a patch in oe-core [OE-core] [PATCH] report-error.bbclass:
> > replace angle brackets with < and >]
> >
> > when we have below content in local.conf or auto.conf:
> > BUILDHISTORY_COMMIT_AUTHOR ?= "Khem Raj"
> > send-error-report will fail with "HTTP Error 500: OK"
> >
> > error-report-web do rudimentary check on all fields that are
> > passed to the graphs page to avoid any XSS happening, if contains
> > '<', the server will return error(Invalid characters in json).
> > fixed by use escape of <> to replace it.
> >
> > NOTE: with this change, error-report-web need to add filter 'safe'
> > for the string wanted to display to avoid further HTML escaping
> > prior to output. Below is how the content displayed on webpage:
> > with the filter 'safe':
> > BUILDHISTORY_COMMIT_AUTHOR ?= "Khem Raj"
> > without the filter 'safe':
> > BUILDHISTORY_COMMIT_AUTHOR ?= "Khem Raj "
> >
> > Do you have good idea to resolve this? Thanks.
Sorry about the delay on this, we do really need to get this resolved.
I'm wondering if we should replace the angled brackets test with
https://github.com/mozilla/bleach which would then remove the need
for these workarounds.
Would you be able to update the patch for the others issues please
and then we can look at this one separately?
Thanks,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52795): https://lists.yoctoproject.org/g/yocto/message/52795
Mute This Topic: https://lists.yoctoproject.org/mt/61340472/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] How can I create a truly minimal distribution that runs entirely from RAM?
On Mon, 2021-03-15 at 17:01 +0100, Zoran wrote: > > How can I instruct Yocto to execute do_image_cpio first? > > YOCTO people are entitled to answer that question. Aren't ya, INTEL folks??? > > Actually, iNTEL (IOTG) is responsible for that (since YOCTO support is > 90% from INTEL), and I assume INTEL YOCTO people are entitled > answering that/// For the record and for the alleviation of any doubt, Intel was one of a group of founders of the project and continues to be a valued contributor but has never been 90% of the project. Intel has reduced its involvement more recently both in Yocto Project and in other open source efforts as it's focus has changed over time. Many of the people who did work for Intel and contributed to the project now work for different organisations but still contribute, Ross and myself included. I'd *strongly* suggest sticking to technical discussion rather than directing comments at any specific company in future. Your comments are confusing and off putting for people. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52717): https://lists.yoctoproject.org/g/yocto/message/52717 Mute This Topic: https://lists.yoctoproject.org/mt/81241640/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Reducing the perl footprint on my image
On Tue, 2021-03-02 at 20:42 +, Diego Santa Cruz via lists.yoctoproject.org wrote: > > -Original Message- > > From: yocto@lists.yoctoproject.org On > > Behalf Of Steve Sakoman via lists.yoctoproject.org > > Sent: 02 March 2021 21:06 > > To: Steve Sakoman > > Cc: rustyhow...@gmail.com; Yocto (yocto@lists.yoctoproject.org) > > > > Subject: Re: [yocto] Reducing the perl footprint on my image > > > > On Tue, Mar 2, 2021 at 10:01 AM Steve Sakoman via > > lists.yoctoproject.org > > wrote: > > > > > > On Tue, Mar 2, 2021 at 6:26 AM wrote: > > > > > > > > I have an image that is using debian package management > > (PACKAGE_CLASSES = "package_deb"). Because apt and dpkg require perl, > > perl is being installed in the image. No problem. Except that the entire > > perl > > stack is 669 packages. > > > > > > I just took a look at the manifest for one of my images that includes > > > PACKAGE_CLASSES = "package_deb". I see the perl package plus 43 > > > perl-module packages. Are you sure that something else in your images > > > isn't pulling in all of those other perl-module packages? > > > > It just occurred to me to make sure you are looking in the image > > manifest to see which packages are actually installed in your image. > > The perl recipe does generate 676 packages (in dunfell) so perhaps you > > might be looking at the generated packages rather than the installed > > packages?? > > > > I encountered a similar problem with package management enabled and rpm > as package format, where I also just install rpm for package management > and not all dnf stack. I get quite a lot of perl and python packages > into the image which are pulled by the rpm package, but they are only > needed for things like rpm-build, rpm-sign, etc., not for the bare > rpm command, which is the only one I need in the image. > > So I locally extended the rpm recipe to split those tools into rpm-build, > rpm-sign and rpm-archive and skip those packages in the image. I should > probably send patches for that to oe-core. Is that something that could > be accepted? Not sure they need to go to separate packages but moving those three to some kind of "build" package would make a lot of sense to me at least. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52560): https://lists.yoctoproject.org/g/yocto/message/52560 Mute This Topic: https://lists.yoctoproject.org/mt/81029247/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Package names in IMAGE_MANIFEST and PACKAGES
On Fri, 2021-02-26 at 14:18 +, Mikko Murto wrote: > Hello, > > I'm developing a meta layer to save details about an image created by Yocto > to an > SPDX document ( https://github.com/doubleopen-project/meta-doubleopen). > > I've encountered two issues regarding package names in IMAGE_MANIFEST > and PACKAGES variables, > > https://github.com/doubleopen-project/meta-doubleopen/issues/2 and > https://github.com/doubleopen-project/meta-doubleopen/issues/3. > > The crux of the matter is that I need to find packages created by recipes > and to link the packages listed in image's manifest files to these packages. > > First, the PACKAGES variable of all recipes doesn't seem to include all > packages created. For example util-linux's PACKAGES doesn't include > util-linux-sulogin, but util-linux-sulogin may be included in an image's > manifest and it has a directory in the packages-split directory of > util-linux. > What would be the correct way to get information about all packages? > > Second, the package names in the image manifest may differ from those in > the PACKAGES variable or in packages-split directory. As an example, a > manifest file may include libkmod2, but recipe for kmod creates package > named libkmod. How to make the link from libkmod2 to libkmod? I'd suggesting looking at packagedata which is how do_package and friends internally looks up things like which recipe provides which package and what the final package name is. An example of this in action is scripts/oe-pkgdata-util. There is also meta/lib/oe/packagedata.py. Sadly the API is horrible, it was never really designed for "public" use but I would love to see a better API around that (maybe one oe-pkgdata-util could use too). Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52494): https://lists.yoctoproject.org/g/yocto/message/52494 Mute This Topic: https://lists.yoctoproject.org/mt/80927769/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [ptest-runner][PATCH v2] Fix inappropriate ioctl when detaching tty
On Fri, 2021-02-19 at 10:18 -0500, Randy MacLeod wrote: > On 2021-02-19 1:44 a.m., Chen Qi wrote: > > Hi Anibal, > > > > The ptest-runner repo seems to be messed up. > > This patch is no longer there, yet the SRCREV in ptest-runner recipe > > refers to this commit. > > > > $ git show 834670317bd3f6e427e1ac461c07ada6b8936dfd > > fatal: bad object 834670317bd3f6e427e1ac461c07ada6b8936dfd > > > > Regards, > > Chen Qi > > This was making our automated builds fail but I've added > the fall-back tarball and that should suffice for now. > > We should probably do something to prevent that but > could someone take a look soon and perhaps restore the repo > from another location? I talked with Anibal and its fixed now. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52401): https://lists.yoctoproject.org/g/yocto/message/52401 Mute This Topic: https://lists.yoctoproject.org/mt/75413484/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-gplv2] [PATCH] disable-gplv3.inc: Update pattern match to what we really mean
This code wants to disable GPLv3 and GPLv3+ however the pattern
didnt specify that and with recent changes in OE-Core, it needs
to be specific. Update the pattern to be specific.
Signed-off-by: Richard Purdie
---
conf/distro/include/disable-gplv3.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/conf/distro/include/disable-gplv3.inc
b/conf/distro/include/disable-gplv3.inc
index 761be7d..bded378 100644
--- a/conf/distro/include/disable-gplv3.inc
+++ b/conf/distro/include/disable-gplv3.inc
@@ -1,3 +1,3 @@
-INCOMPATIBLE_LICENSE = '*GPLv3'
+INCOMPATIBLE_LICENSE = '*GPLv3*'
WARN_QA_remove = 'incompatible-license'
RDEPENDS_${PN}-ptest_remove_pn-glib-2.0 = "python3-dbusmock"
--
2.27.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52394): https://lists.yoctoproject.org/g/yocto/message/52394
Mute This Topic: https://lists.yoctoproject.org/mt/80744751/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [qa-build-notification] [yocto] QA notification for completed autobuilder build (yocto-3.2.2.rc1)
On Thu, 2021-02-18 at 14:58 +0100, Yann Dirson wrote: > > > Le mar. 16 févr. 2021 à 18:43, Pokybuild User > a écrit : > > > > Build hash information: > > > > bitbake: 0a3bf681530bd63fc0036ca81ef868ab53fde56c > > meta-arm: aa63e31b6edb5197764c21434219050ab51f0fbd > > meta-gplv2: 6e8e969590a22a729db1ff342de57f2fd5d02d43 > > meta-intel: 1d866c58534eb1d317b7a674c6e6c57ab9594fb0 > > meta-kernel: f793168bd19af3d8c5a260dd35f387ed9a31794b > > meta-mingw: 352d8b0aa3c7bbd5060a4cc2ebe7c0e964de4879 > > oecore: ebaaee50cb3ac75112827f935c48affaf622ce7f > > poky: d5d6286a66f46f4523e35e0e3f20cd7396195fdc > > > > Is it expected that the noted meta-arm sha1 is on branch "master" and not > "gatesgarth" ? Not expected but we worked it out. There is a patch from Ross on this list which fixes the issue in yocto-autobuilder2. For the purposes of the release I'm thinking we should rerun the meta-arm tests and swap in the gatesgarth revision. Copying Vineela/Michael so they know about the issue. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52384): https://lists.yoctoproject.org/g/yocto/message/52384 Mute This Topic: https://lists.yoctoproject.org/mt/80729436/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Timing a recipe
On Tue, 2021-02-16 at 11:43 -0800, rustyhow...@gmail.com wrote: > "time bitbake recipe" is perfect for manual things. But I wanted to > also measure the recipe times when building the entire image. I > ended up creating a bbappend with new pre/post tasks for the main > tasks (fetch, unpack, configure, compile, install, package). The > pre task drops a timestamp file and the post task reads the file, > calculates the elapsed time and logs it to a file. It's a bit clunky > but it gives the information I want. Thanks for the help. As others have said, please look at the buildstats class and the data it saves into TMPDIR/buildstats. It should do what you want and we have tools like pybootchart which can show it visually. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52363): https://lists.yoctoproject.org/g/yocto/message/52363 Mute This Topic: https://lists.yoctoproject.org/mt/80662724/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [prelink-cross][PATCH] Add SPDX license headers to all source files
On Tue, 2021-02-02 at 11:54 +0100, Meh Mbeh Ida Delphine wrote: > From: Meh Mbeh Ida Delphine > > Added SPDX headers in all source files except src/makecrc.c since it is not > copyrighted. > Skipped Makefile.am as well. > Also cleared redundant license text. > Updated README file with correct email addresses. > > Fixes: [YOCTO #13529] Thanks for this. There are a couple of tweaks I noticed as I was about to merge it. Firstly, can you make the email address update a separate commit please. Commits should do one logical thing. > > - The GNU C Library is free software; you can redistribute it and/or > - modify it under the terms of the GNU Lesser General Public > - License as published by the Free Software Foundation; either > - version 2.1 of the License, or (at your option) any later version. > - > - The GNU C Library is distributed in the hope that it will be useful, > - but WITHOUT ANY WARRANTY; without even the implied warranty of > - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > - Lesser General Public License for more details. > - > - You should have received a copy of the GNU Lesser General Public > - License along with the GNU C Library; if not, write to the Free > - Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA > - 02111-1307 USA. */ > +* SPDX-License-Identifier: GPL-2.0-or-later > +*/ > This file mentions "GNU Lesser General Public License" and version 2.1 which is not GPL-2.0! It is critical to get this bit right. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52223): https://lists.yoctoproject.org/g/yocto/message/52223 Mute This Topic: https://lists.yoctoproject.org/mt/80311841/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [OE-core] Let me tell you how I really feel. Zero filter. If you need meta-python2, you need to become a maintainer. Immediately. Period.
On Mon, 2021-02-01 at 15:40 +0100, Martin Jansa wrote: > can I get the write access to meta-python2 as mentioned above? > > I have 2 fixes to make it parse able with latest oe-core: > https://lists.openembedded.org/g/openembedded-devel/message/89201 > https://lists.openembedded.org/g/openembedded-devel/message/89200 > > to fix issues discussed in: > https://github.com/openembedded/openembedded-core/commit/fd6a007efa7cb45101a66f294af81d9d33bb3fab#commitcomment-46565284 > https://lists.openembedded.org/g/openembedded-core/message/147477 > https://lists.openembedded.org/g/openembedded-core/message/147514 This sounds like a good idea to me and I have admin right so I've given you access :) Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52184): https://lists.yoctoproject.org/g/yocto/message/52184 Mute This Topic: https://lists.yoctoproject.org/mt/80286758/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [yocto] QA notification for completed autobuilder build (yocto-3.3_M2.rc1)
On Wed, 2021-01-27 at 09:45 +, Jose Quaresma wrote: > Hi All, > gstreamer1.0: fix failing ptest > https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=7b90027aac9fa41b3dc98765151d761df8dabb97 > > Is this commit present yocto-3.3_M2.rc1 ? Just to confirm, it wasn't so this should be fixed for M3, thanks! Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52168): https://lists.yoctoproject.org/g/yocto/message/52168 Mute This Topic: https://lists.yoctoproject.org/mt/80255578/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] SDKMACHINE and ppc64le issue with latest head?
On Fri, 2021-01-29 at 13:48 -0600, Andrew Geissler wrote:
>
> > On Jan 29, 2021, at 10:54 AM, Richard Purdie
> > wrote:
> >
> > On Fri, 2021-01-29 at 08:40 -0800, Andrew Geissler wrote:
> > > > What was SDKMACHINE set to before?
> > >
> > > Hey Richard, thanks for the quick response.
> > >
> > > We did not have it set. It looks like this recent commit is what
> > > changed things on us:
> > >
> > > commit c74ec1dd7393b9dc7bec1a3ca2ed0a56fb18d8fb
> > > Author: Ross Burton
> > > Date: Tue Dec 22 17:23:14 2020 +
> > >
> > > bitbake.conf: default SDKMACHINE to the build host architecture
> > >
> > >
> > > Looks like I need to submit a patch to y'all to add a ppc64le.conf to
> > > conf/machine-sdk/?
> >
> > That would likely avoid the failures you're seeing, yes.
> >
> > I really wish we had better support for ppc64le both for hosts and
> > targets and had people actively involved/maintaining the ppc support,
> > its in need of massive modernisation particularly on the target side.
>
> Darn, I tried just adding this:
>
> cat meta/conf/machine-sdk/ppc64le.conf
>
> SDK_ARCH = "ppc64le"
> ABIEXTENSION_class-nativesdk = ""
>
> I get further but then hit a bunch of fails like this:
>
> ERROR:
> /home/andrewg/Code/openbmc/meta/recipes-devtools/meson/nativesdk-meson_0.56.0.bb:
> Unable to determine endianness for architecture '${SDK_ARCH}'
> ERROR:
> /home/andrewg/Code/openbmc/meta/recipes-devtools/meson/nativesdk-meson_0.56.0.bb:
> Please add your architecture to siteinfo.bbclass
> ERROR: Failed to parse recipe:
> /home/andrewg/Code/openbmc/meta/recipes-devtools/meson/nativesdk-meson_0.56.0.bb
> ERROR:
> /home/andrewg/Code/openbmc/meta/recipes-graphics/xorg-lib/libxext_1.3.4.bb:
> Unable to determine endianness for architecture '${SDK_ARCH}'
> ERROR:
> /home/andrewg/Code/openbmc/meta/recipes-graphics/xorg-lib/libxext_1.3.4.bb:
> Please add your architecture to siteinfo.bbclass
> …
>
> I’m did some grepping around but don’t see anything obvious. Why is it not
> finding the SDK_ARCH I’ve set in the new conf file?
>
> Wondering if I should just go with my first workaround and set
> SDKMACHINE=x86_64.
> Apparently using that default in the past hasn’t affected our use cases.
SDKMACHINE is the machine to run any SDK that is built on. If you're
not building an SDK or eSDK, it won't matter to your use case.
BUILD_ARCH is the machine you're building upon which is already being
set correctly and unchanged.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52159): https://lists.yoctoproject.org/g/yocto/message/52159
Mute This Topic: https://lists.yoctoproject.org/mt/80210879/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] SDKMACHINE and ppc64le issue with latest head?
On Fri, 2021-01-29 at 08:40 -0800, Andrew Geissler wrote: > > What was SDKMACHINE set to before? > > Hey Richard, thanks for the quick response. > > We did not have it set. It looks like this recent commit is what > changed things on us: > > commit c74ec1dd7393b9dc7bec1a3ca2ed0a56fb18d8fb > Author: Ross Burton > Date: Tue Dec 22 17:23:14 2020 + > > bitbake.conf: default SDKMACHINE to the build host architecture > > > Looks like I need to submit a patch to y'all to add a ppc64le.conf to > conf/machine-sdk/? That would likely avoid the failures you're seeing, yes. I really wish we had better support for ppc64le both for hosts and targets and had people actively involved/maintaining the ppc support, its in need of massive modernisation particularly on the target side. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52153): https://lists.yoctoproject.org/g/yocto/message/52153 Mute This Topic: https://lists.yoctoproject.org/mt/80210879/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] SDKMACHINE and ppc64le issue with latest head?
On Fri, 2021-01-29 at 06:38 -0800, Andrew Geissler wrote: > Over in OpenBMC, we utilize a mix of x86 and ppc64le machines for our > CI. > > Our latest rebase of poky master > (https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/39533/) has > started failing to compile on our ppc64le machines with the below > error. > > I can workaround it by setting "SDKMACHINE=x86_64" but that seems a > bit weird on a ppc64le machine? > > + bitbake obmc-phosphor-image obmc-phosphor-debug-tarball > ERROR: OE-core's config sanity checker detected a potential > misconfiguration. > Either fix the cause of this error or at your own risk disable > the checker (see sanity.conf). > Following is the list of potential problems / advisories: > > Specified SDKMACHINE value is not valid What was SDKMACHINE set to before? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52151): https://lists.yoctoproject.org/g/yocto/message/52151 Mute This Topic: https://lists.yoctoproject.org/mt/80210879/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] git lfs not working in dunfell
On Thu, 2021-01-28 at 16:18 +0100, Marek Belisko wrote: > Hi, > > I have repo where I'm using lfs. I've added to my SRC_URI = > "git://.. ;lfs=1" and the project is fetched but the issue is that > lfs files are shown as references only (content is not fetched). > I briefly checked git fetcher in bitbake and seems it checks that repo > have lfs content but I cannot see anywhere git lfs pull to actually > pull lfs content. Am I missing something? When checked poky master it > looks like proper fetching is in place. Is there any way how to get it > to dunfell LTS release? Thanks. There is a patch in bitbake master related to this which you may want to test and maybe request for adding to dunfell if it helps. https://git.openembedded.org/bitbake/commit/?id=0efac66043662e7a2027192f50e92e982db2ba1c Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52143): https://lists.yoctoproject.org/g/yocto/message/52143 Mute This Topic: https://lists.yoctoproject.org/mt/80185549/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-mingw] [PATCH 2/2] README: Add instructions for configuring git repo for sending patches
Signed-off-by: Richard Purdie --- README | 6 ++ 1 file changed, 6 insertions(+) diff --git a/README b/README index c17f74a..af3ace9 100644 --- a/README +++ b/README @@ -15,3 +15,9 @@ Layer Maintainer: Joshua Watt Please send changes to the yocto mailing list with [meta-mingw] in the subject line, cc'ing the maintainer. + +This can be configured within the repository with the commands: + +git config sendemail.to yocto@lists.yoctoproject.org +git config sendemail.cc jpewhac...@gmail.com +git config format.subjectprefix "meta-mingw] [PATCH" -- 2.27.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52142): https://lists.yoctoproject.org/g/yocto/message/52142 Mute This Topic: https://lists.yoctoproject.org/mt/80206710/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-mingw] [PATCH 1/2] libiconv: Update to work with autoconf 2.70
Signed-off-by: Richard Purdie
---
.../libiconv/libiconv/autoconf270.patch | 17 +
recipes-support/libiconv/libiconv_1.15.bb | 3 ++-
2 files changed, 19 insertions(+), 1 deletion(-)
create mode 100644 recipes-support/libiconv/libiconv/autoconf270.patch
diff --git a/recipes-support/libiconv/libiconv/autoconf270.patch
b/recipes-support/libiconv/libiconv/autoconf270.patch
new file mode 100644
index 000..17e6e0b
--- /dev/null
+++ b/recipes-support/libiconv/libiconv/autoconf270.patch
@@ -0,0 +1,17 @@
+Update to add the required gettext version to work with autoconf 2.70
+
+Upstream-Status: Pending
+RP - 2021/1/28
+
+Index: libiconv-1.15/configure.ac
+===
+--- libiconv-1.15.orig/configure.ac
libiconv-1.15/configure.ac
+@@ -98,6 +98,7 @@ fi
+ gl_VISIBILITY
+ AM_ICONV
+ AM_GNU_GETTEXT([external], [need-ngettext])
++AM_GNU_GETTEXT_VERSION([0.21])
+
+ dnl checks for typedefs
+
diff --git a/recipes-support/libiconv/libiconv_1.15.bb
b/recipes-support/libiconv/libiconv_1.15.bb
index e3eacd9..df7f527 100644
--- a/recipes-support/libiconv/libiconv_1.15.bb
+++ b/recipes-support/libiconv/libiconv_1.15.bb
@@ -10,7 +10,8 @@ LICENSE = "LGPLv3"
LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=9f604d8a4f8e74f4f5140845a21b6674 \
file://libcharset/COPYING.LIB;md5=9f604d8a4f8e74f4f5140845a21b6674"
-SRC_URI = "${GNU_MIRROR}/${BPN}/${BPN}-${PV}.tar.gz"
+SRC_URI = "${GNU_MIRROR}/${BPN}/${BPN}-${PV}.tar.gz \
+ file://autoconf270.patch"
SRC_URI[md5sum] = "ace8b5f2db42f7b3b3057585e80d9808"
SRC_URI[sha256sum] =
"ccf536620a45458d26ba83887a983b96827001e92a13847b45e4925cc8913178"
--
2.27.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52141): https://lists.yoctoproject.org/g/yocto/message/52141
Mute This Topic: https://lists.yoctoproject.org/mt/80206709/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-gplv2] [PATCH 3/3] grep: Update to work with autoconf 2.70
Signed-off-by: Richard Purdie
---
.../grep/grep-2.5.1a/autoconf270.patch| 27 +++
recipes-extended/grep/grep_2.5.1a.bb | 1 +
2 files changed, 28 insertions(+)
create mode 100644 recipes-extended/grep/grep-2.5.1a/autoconf270.patch
diff --git a/recipes-extended/grep/grep-2.5.1a/autoconf270.patch
b/recipes-extended/grep/grep-2.5.1a/autoconf270.patch
new file mode 100644
index 000..fe2cb0b
--- /dev/null
+++ b/recipes-extended/grep/grep-2.5.1a/autoconf270.patch
@@ -0,0 +1,27 @@
+Update to add the required gettext version to work with autoconf 2.70
+
+Also the script needs CPP so add the appropriate macro.
+
+Upstream-Status: Inappropriate [needed for old GPLv2 version only]
+RP - 2021/1/28
+
+Index: grep-2.5.1a/configure.in
+===
+--- grep-2.5.1a.orig/configure.in
grep-2.5.1a/configure.in
+@@ -27,6 +27,7 @@ AC_PROG_AWK
+ AC_PROG_CC
+ AC_PROG_INSTALL
+ AC_PROG_RANLIB
++AC_PROG_CPP
+
+ dnl Checks for typedefs, structures, and compiler characteristics.
+ AC_SYS_LARGEFILE
+@@ -73,6 +74,7 @@ esac
+ dnl I18N feature
+ ALL_LINGUAS="cs de el eo es et fr gl hr id it ja ko nl no pl pt_BR ru sl sv"
+ AM_GNU_GETTEXT([external])
++AM_GNU_GETTEXT_VERSION([0.21])
+
+ dnl DOS file name convention
+ dnl sets HAVE_DOS_FILE_NAMES
diff --git a/recipes-extended/grep/grep_2.5.1a.bb
b/recipes-extended/grep/grep_2.5.1a.bb
index d3b4ddc..5445c7e 100644
--- a/recipes-extended/grep/grep_2.5.1a.bb
+++ b/recipes-extended/grep/grep_2.5.1a.bb
@@ -18,6 +18,7 @@ SRC_URI = "${GNU_MIRROR}/grep/grep-${PV}.tar.bz2 \
file://grep-egrep-fgrep-Fix-LSB-NG-cases.patch \
file://search-fix-compilation-error-with-security-flags-ena.patch \
file://0001-Fix-builds-with-gettext-0.20.patch \
+ file://autoconf270.patch \
"
SRC_URI[md5sum] = "52202fe462770fa6be1bb667bd6cf30c"
--
2.27.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52140): https://lists.yoctoproject.org/g/yocto/message/52140
Mute This Topic: https://lists.yoctoproject.org/mt/80206383/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-gplv2] [PATCH 2/3] diffutils: Update to work with autoconf 2.70
Signed-off-by: Richard Purdie
---
.../diffutils/diffutils-2.8.1/autoconf270.patch | 17 +
recipes-extended/diffutils/diffutils_2.8.1.bb | 1 +
2 files changed, 18 insertions(+)
create mode 100644 recipes-extended/diffutils/diffutils-2.8.1/autoconf270.patch
diff --git a/recipes-extended/diffutils/diffutils-2.8.1/autoconf270.patch
b/recipes-extended/diffutils/diffutils-2.8.1/autoconf270.patch
new file mode 100644
index 000..5651675
--- /dev/null
+++ b/recipes-extended/diffutils/diffutils-2.8.1/autoconf270.patch
@@ -0,0 +1,17 @@
+Update to add the required gettext version to work with autoconf 2.70
+
+Upstream-Status: Inappropriate [needed for obsolete GPLv2 version]
+RP - 2021/1/28
+
+Index: diffutils-2.8.1/configure.ac
+===
+--- diffutils-2.8.1.orig/configure.ac
diffutils-2.8.1/configure.ac
+@@ -62,6 +62,7 @@ AC_CHECK_TYPE(ptrdiff_t, int)
+ AC_CHECK_TYPE(ssize_t, int)
+ jm_AC_TYPE_UINTMAX_T
+ AM_GNU_GETTEXT([external])
++AM_GNU_GETTEXT_VERSION([0.21])
+ XGETTEXT="AWK='$AWK' \$(SHELL) \$(top_srcdir)/exgettext $XGETTEXT"
+ AC_HEADER_DIRENT
+ AC_HEADER_STAT
diff --git a/recipes-extended/diffutils/diffutils_2.8.1.bb
b/recipes-extended/diffutils/diffutils_2.8.1.bb
index 7c43c4b..88d189d 100644
--- a/recipes-extended/diffutils/diffutils_2.8.1.bb
+++ b/recipes-extended/diffutils/diffutils_2.8.1.bb
@@ -11,6 +11,7 @@ SRC_URI = "${GNU_MIRROR}/diffutils/diffutils-${PV}.tar.gz \
file://0001-Make-it-build-with-compile-time-hardening-enabled.patch
\
file://0002-included-libc-use-mempcpy-instead-of.patch \
file://0003-context-fix-compilation-with-64bit-time_t-on-32bit-a.patch \
+ file://autoconf270.patch \
"
SRC_URI[md5sum] = "71f9c5ae19b60608f6c7f162da86a428"
--
2.27.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52139): https://lists.yoctoproject.org/g/yocto/message/52139
Mute This Topic: https://lists.yoctoproject.org/mt/80206382/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-gplv2] [PATCH 1/3] bash: Update to work with autoconf 2.70
Signed-off-by: Richard Purdie
---
.../bash/bash-3.2.57/autoconf270.patch | 17 +
recipes-extended/bash/bash_3.2.57.bb| 1 +
2 files changed, 18 insertions(+)
create mode 100644 recipes-extended/bash/bash-3.2.57/autoconf270.patch
diff --git a/recipes-extended/bash/bash-3.2.57/autoconf270.patch
b/recipes-extended/bash/bash-3.2.57/autoconf270.patch
new file mode 100644
index 000..2249bb9
--- /dev/null
+++ b/recipes-extended/bash/bash-3.2.57/autoconf270.patch
@@ -0,0 +1,17 @@
+Update to add the required gettext version to work with autoconf 2.70
+
+Upstream-Status: Inappropriate [required for bash 3.2.57 (GPLv2) recipe only]
+RP - 2021/1/28
+
+Index: bash-3.2.57/configure.in
+===
+--- bash-3.2.57.orig/configure.in
bash-3.2.57/configure.in
+@@ -625,6 +625,7 @@ AC_C_CHAR_UNSIGNED
+
+ dnl initialize GNU gettext
+ AM_GNU_GETTEXT([no-libtool], [need-ngettext], [lib/intl])
++AM_GNU_GETTEXT_VERSION([0.21])
+
+ dnl header files
+ AC_HEADER_DIRENT
diff --git a/recipes-extended/bash/bash_3.2.57.bb
b/recipes-extended/bash/bash_3.2.57.bb
index 5c288b3..f4db7a5 100644
--- a/recipes-extended/bash/bash_3.2.57.bb
+++ b/recipes-extended/bash/bash_3.2.57.bb
@@ -10,6 +10,7 @@ SRC_URI = "${GNU_MIRROR}/${BPN}/${BP}.tar.gz \
file://run-ptest \
file://dont-include-target-CFLAGS-in-host-LDFLAGS.patch \
file://string-format.patch \
+ file://autoconf270.patch \
"
SRC_URI[md5sum] = "237a8767c990b43ae2c89895c2dbc062"
--
2.27.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52138): https://lists.yoctoproject.org/g/yocto/message/52138
Mute This Topic: https://lists.yoctoproject.org/mt/80206381/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Task only for target recipe
On Thu, 2021-01-28 at 18:53 +0100, Ayoub Zaki via
lists.yoctoproject.org wrote:
> Hello I created a new task that I want to run for every recipe of my
> image but only for target recipes and skip all native, sdk,...
> mytask.bbclass:
>
> addtask do_mytask after do_install
>
> do_mytask() {
> :
> }
>
> do_mytask_class-target() {
>
> bbwarn "mytask"
> :
> }
>
> I added to local.conf :
>
> INHERIT += "mytask"
>
> I don't see it running! what is the proper way to achieve this?
How are you running it? You've said you want it to run after do_install
but not what should trigger it.
Adding "before do_build" to the addtask line for example might trigger
it (do_build is the default task).
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52136): https://lists.yoctoproject.org/g/yocto/message/52136
Mute This Topic: https://lists.yoctoproject.org/mt/80189701/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Including binary application as part of the image output
On Wed, 2021-01-27 at 10:32 -0800, chuck kamas via lists.yoctoproject.org wrote: > > As part of our image we build our company's application. This > application becomes part of the image and is executed when the image boots. > > My question is how to have the binary image also be available along with > the image's wic file? Is there a line I can add to a recipe to have it > copy that image file to the tmp/deploy directory or other appropriate > directory so that it is available? You could add a "do_deploy" task that places it there. See meta/classes/deploy.bbclass and other recipes which add such a task. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52129): https://lists.yoctoproject.org/g/yocto/message/52129 Mute This Topic: https://lists.yoctoproject.org/mt/80164330/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] openjdk-8 multilib
On Tue, 2021-01-26 at 09:00 -0800, Rudolf J Streif wrote:
> I have been scratching my head over building openjdk-8 with multilib for
> an aarch64 system. Essentially, I want to use 32-bit OpenJDK on the
> 64-bit system.
>
> Theoretically adding to local.conf
>
> require conf/multilib.conf
> MULTILIBS = "multilib:lib32"
> DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a"
>
> and then building lib32-openjdk-8 should do the trick. However, it does not:
>
> $ bitbake lib32-openjdk-8
>
> ERROR: Nothing PROVIDES 'lib32-openjdk-8'
> lib32-openjdk-8 was skipped: incompatible with host
> arm-fslcmllib32-linux-gnueabi (not in COMPATIBLE_HOST)
>
> The openjdk-8 recipe sets architecture dependency by selectively
> including an include file:
>
> INC_FILE_SUFFIX = ""
> INC_FILE_SUFFIX_aarch64 = "-aarch64"
> INC_FILE_SUFFIX_armv7a = "-aarch32"
> INC_FILE_SUFFIX_armv7ve = "-aarch32"
> require openjdk-8-release${INC_FILE_SUFFIX}.inc
> require openjdk-8-cross.inc
I suspect that at this point in the parse, the mulitlib code hasn't
swizzled the bits around so it still looks like the main lib rather
than the mutlilib.
Including a variable in a require like that is an immediate expansion
operation so it can't be "undone" when things get properly setup later.
Offhand I'm not sure what you'd do to avoid this. The multilibs are all
a bit ugly in some ways. It suggests they need to be setting up the
overrides earlier. The assumption in the code is that people don't use
immediate expansion for this reason.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52102): https://lists.yoctoproject.org/g/yocto/message/52102
Mute This Topic: https://lists.yoctoproject.org/mt/80135247/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] #yocto #kernel BB_GENERATE_MIRROR_TARBALLS
On Tue, 2021-01-19 at 20:22 +, Monsees, Steven C (US) wrote: > All but the following downloaded except these which failed (timing out): > > https://sourceware.org/elfutils/ftp/0.177/elfutils-0.177.tar.bz2 > https://download.qemu.org/qemu-4.1.0.tar.xz > http://libarchive.org/downloads/libarchive-3.4.0.tar.gz > > fyi... I am using zeus 3.0.4. I did just check and these do seem to download ok here: $ wget https://download.qemu.org/qemu-4.1.0.tar.xz --2021-01-19 21:09:28-- https://download.qemu.org/qemu-4.1.0.tar.xz Resolving download.qemu.org (download.qemu.org)... 172.99.69.163 Connecting to download.qemu.org (download.qemu.org)|172.99.69.163|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 54001708 (52M) [application/x-xz] Saving to: ‘qemu-4.1.0.tar.xz’ qemu-4.1.0.tar.xz 100%[===>] 51.50M 8.77MB/sin 6.3s 2021-01-19 21:09:35 (8.21 MB/s) - ‘qemu-4.1.0.tar.xz’ saved [54001708/54001708] $ wget https://sourceware.org/elfutils/ftp/0.177/elfutils-0.177.tar.bz2 --2021-01-19 21:09:38-- https://sourceware.org/elfutils/ftp/0.177/elfutils-0.177.tar.bz2 Resolving sourceware.org (sourceware.org)... 2620:52:3:1:0:246e:9693:128c, 8.43.85.97 Connecting to sourceware.org (sourceware.org)|2620:52:3:1:0:246e:9693:128c|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 8852413 (8.4M) [application/x-bzip2] Saving to: ‘elfutils-0.177.tar.bz2’ elfutils-0.177.tar.bz2 100%[===>] 8.44M 5.87MB/sin 1.4s 2021-01-19 21:09:40 (5.87 MB/s) - ‘elfutils-0.177.tar.bz2’ saved [8852413/8852413] $ wget http://libarchive.org/downloads/libarchive-3.4.0.tar.gz --2021-01-19 21:09:46-- http://libarchive.org/downloads/libarchive-3.4.0.tar.gz Resolving libarchive.org (libarchive.org)... 2600:9000:21c7:e600:16:e6b0:f440:93a1, 2600:9000:21c7:9000:16:e6b0:f440:93a1, 2600:9000:21c7:2e00:16:e6b0:f440:93a1, ... Connecting to libarchive.org (libarchive.org)|2600:9000:21c7:e600:16:e6b0:f440:93a1|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 6908093 (6.6M) [application/octet-stream] Saving to: ‘libarchive-3.4.0.tar.gz’ libarchive-3.4.0.tar.gz 100%[===>] 6.59M 8.25MB/sin 0.8s 2021-01-19 21:09:47 (8.25 MB/s) - ‘libarchive-3.4.0.tar.gz’ saved [6908093/6908093] $ sha256sum libarchive-3.4.0.tar.gz elfutils-0.177.tar.bz2 qemu-4.1.0.tar.xz 8643d50ed40c759f5412a3af4e353cffbce4fdf3b5cf321cb72cacf06b2d825e libarchive-3.4.0.tar.gz fa489deccbcae7d8c920f60d85906124c1989c591196d90e0fd668e3dc05042e elfutils-0.177.tar.bz2 656e60218689bdeec69903087fd7582d5d3e72238d02f4481d8dc6d79fd909c6 qemu-4.1.0.tar.xz Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52054): https://lists.yoctoproject.org/g/yocto/message/52054 Mute This Topic: https://lists.yoctoproject.org/mt/79951152/21656 Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto Mute #kernel:https://lists.yoctoproject.org/g/yocto/mutehashtag/kernel Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
