As part of the merging builds, installation of target.json was lost
causing `rustc` to fail on startup with:
error: Error loading target specification: Could not find specification for target "aarch64-poky-linux-gnu". Run `rustc --print target-list` for a list of built-in targets
We know the full target specification, so just install it directly
rather than using the glob approach from previously.
Fixes: b9b0cd99cdc7 ("rust: Enable nativesdk and target builds + replace rust-tools-cross-canadian")
(From OE-Core rev: b187185ceecf1c852b1fdc47451d157a41962d69)
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
GTK+ 3.24.36 will drop the autotools build, so get ahead of the curve
and switch to Meson.
The tarball is missing one meson.build file so add that explictly for
now.
(From OE-Core rev: f9b0930eab6cf89bbf80c565676c89997b610206)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
LICENSE for curl is set to MIT-open-group which is wrong and proper
license is 'curl'
I check below link and the line "Curl and libcurl are licensed under
the license below, which is inspired by MIT/X, but not identical." says
that the license is identical to MIT but actual license is identical
from the file "meta/files/common-licenses/curl"
Link: https://curl.se/docs/copyright.html
Also, I do not find the MIT-open-group license text in the entire
source-code
(From OE-Core rev: 34b228bd3a80a74bf4d84ef7ee362f4ab1e3a466)
Signed-off-by: Ranjitsinh Rathod <ranjitsinh.rathod@kpit.com>
Signed-off-by: Ranjitsinh Rathod <ranjitsinhrathod1991@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With Linux 6.1.0 and perf 1.0-r9, a build which includes perf-dev fails due
to perf-dev depending on perf 6.6.1.0-r9 . This is because translate_vers()
operates on perf-dev and mangles its version. The following scenario occurs:
ver=6.1.0-r9
pv=1.0
pkgv=6.1.0
reppv=6.1.0
With Linux 6.1.0, a corner case is hit where pv is a substring of ver, which
yields this corrupted version 6.6.1.0-r9 . Example in python3:
>>> "6.1.0-r9".replace("1.0", "6.1.0")
'6.6.1.0-r9'
>>> "6.0.13-r9".replace("1.0", "6.0.13")
'6.0.13-r9'
The fix is to only replace pv with reppv in case pv is at the beginning
of ver , instead of replacing all occurences.
(From OE-Core rev: bf2096a43d56c2d633a4b6e3db9e4390da4be6e2)
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I meant to do this whilst merging but messed up the patches. This
file is a .inc file and should match the others.
(From OE-Core rev: d9398dfb0866a5be9ed09ae15902606fe11da2d2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
gcr-3 recipe is still needed for gnome projects that stick to gtk+3, rename to gcr3.
(From OE-Core rev: d0ebe63698470fb3336cc02db698cafacedbd070)
Signed-off-by: Markus Volk <f_l_k@t-online.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Check for known symbols that should have been redirected to 64bit
variants when -D_FILE_OFFSET_BITS=64 and -D_TIME_BITS=64 are set.
(From OE-Core rev: 8e2af04f24443fad2040bb32e6033d49e3120517)
Signed-off-by: Ola x Nilsson <olani@axis.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that bitbake can look into python module code variable and function
dependencies, there are a few extra basic variables we need to exclude.
This is done per function since it keeps the main exclusion list cleaner
and is also slightly faster.
(From OE-Core rev: 870c324d47f1d920fcb736e09fc6e857f24945c7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need to be able to exclude dependencies from the python module
dependency code. Add support for the vardepexclude flag for these. It
only works from the configuration namespace rather than per recipe
for efficiency.
(Bitbake rev: 1aa672b01037fda4ca82f2c7e394783287c09ecd)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Moving code into python modules is a very effective way to reduce parsing
time and overhead in recipes. The downside has always been that any
dependency information on which variables those functions access is lost
and the hashes can therefore become less reliable.
This patch adds parsing of the imported module functions and that dependency
information is them injected back into the hash dependency information.
Intermodule function references are resolved to the full function
call names in our module namespace to ensure interfunction dependencies
are correctly handled too.
(Bitbake rev: 605c478ce14cdc3c02d6ef6d57146a76d436a83c)
(Bitbake rev: 91441e157e495b02db44e19e836afad366ee8924)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
"fn" can mean different things in bitbake, we added support for class
extensions and then mutlticonfigs by extending it. In siggen, it generally
means that mc is prefixed to it and that it is a virtual filename.
Replace "fn" with "mcfn" in the code to make this clearer as if I'm getting
confused, everyone else likely is as well. "mcfn" is sometimes referred
to as taskfn as well but mcfn is probably the easiest to understand as the
taskname isn't included.
(Bitbake rev: e1c1139ab90f8da1b5036db11d943daefbe87859)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current method of passing either a task's datastore, or
dataCaches and a filename into the stamp functions is rather
horrible.
Due to the different contexts, fixing this is hard but we do control
the bitbake side of the API usage so we can migrate those to use other
functions and then only support a datastore in the public bb.build API
which is only called from task context in OE-Core.
(Bitbake rev: c79ecec580e4c2a141ae483ec0f6448f70593dcf)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
One of the challenges in maintaining the code is that it sometimes uses
a datacaches structure and sometimes a datastore. Rather than continue
the current dual API madness, have the worker contexts create a dummy
datacaches structure with the entries we need. Whilst this does need to
be kept in sync with the real structure, that doesn't change and this
allows the code to be simplified.
With this new approach, we can unify the stamps dependency code again.
(Bitbake rev: c6d325fc9b53e9d588ab273ee3c2a99a70fba42c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that we have cache support for the taskdep/gendep/lookupcache data,
we can switch to use that cooker feature and skip the secondary reparse to
write the sig files. This does make the initial parse longer but means the
secondary one isn't needed.
At present parsing with the larger cache isn't optimal but we have plans
in place which will make this faster than the current reparse code being
removed here.
(Bitbake rev: 5951b5b56449855bc2a30146af65eb287a35fcef)
(Bitbake rev: 1252e5bce51ae912ecff9dcc354a371786ff2c72)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It is becomming clear the siggen needs access to our cache data but we
can't always obtain it in the contexts we need to. Add it directly,
meaning over time we should be able to simplify the APIs and stop
convoluting new ones!
(Bitbake rev: 6b213590ed0e77683cf7fbce6bbe9605ddecf3d3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit ef0d0734866505c1c6e0528a0423e7248afb3ff8.
We can't do this since the initramfs needs to use DEPLOY_DIR_IMAGE which isnt
ready until do_image_complete.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In order to build a fitimage, we don't need the image to be "complete"
but we need the cpio portion of it built since the cpio is what ends
up inside the FIT. By reducing the dependency to `do_image_cpio` we
are able to include an image's rootfs as the ramdisk for a FIT and
then bundle that FIT into a larger SPI flash layout.
(From OE-Core rev: ef0d0734866505c1c6e0528a0423e7248afb3ff8)
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The gtktypefuncs.c removal is obsolete as that file isn't in the tarball
anymore, so remove it.
However the wayland-scanner files are still in the tarball despite
efforts to stop this, so generalise the removal to ensure it covers all
files which may be affected. Further investigation will be needed to
see if this is still an issue.
Rebase 0003-Add-disable-opengl-configure-option.patch.
(From OE-Core rev: cf5c5b4b83642ea44b21d29e7c59342666fbda6d)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Invoking meson with just paths is a deprecated use of the binary and
causes warnings, so call 'meson setup' explicitly.
Whilst doing this cleanup, we can also call 'meson compile' and 'meson
install' instead of ninja.
(From OE-Core rev: b248cb1ada04f57a5c4590c7e5efa04f68bc8843)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch disables is_debianlike() so that it always returns False in the
name of deterministic builds. However, the caller default_libdir() then
looks at the host filesystem to decide if /usr/lib64 exists and will
return either lib or lib64, so it still isn't deterministic.
This is only used for the default libdir value and meson.bbclass
always passes an explicit --libdir, so this is moot.
(From OE-Core rev: af4200197948f4900761cb1db11680aeab286f92)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changelog:
==========
* Changed the error handler of oversized chunks (i.e. larger than
PNG_USER_CHUNK_MALLOC_MAX) from png_chunk_error to png_benign_error.
* Fixed a buffer overflow error in contrib/tools/pngfix.
* Fixed a memory leak (CVE-2019-6129) in contrib/tools/pngcp.
* Disabled the ARM Neon optimizations by default in the CMake file,
following the default behavior of the configure script.
* Allowed configure.ac to work with the trunk version of autoconf.
* Removed the support for "install" targets from the legacy makefiles;
removed the obsolete makefile.cegcc.
* Cleaned up the code and updated the internal documentation.
(From OE-Core rev: 19799cb50a00561b318cba1c8c20737f20e4a47f)
Signed-off-by: Wang Mingyu <wangmy@fujitsu.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By default GOCACHE is set to $HOME/.cache.
Same issue for all other go recipes had been fixed by commit 9a6d208b:
[ go: avoid host contamination by GOCACHE ]
but that commit missed go-crosssdk recipe.
(From OE-Core rev: e5fd10c647ac4baad65f9efa964c3380aad7dd10)
Signed-off-by: Robert Andersson <robert.m.andersson@atlascopco.com>
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We're struggling to understand how bitbake.sock can sometimes disappear
in live builds when we can't see where it could have been deleted.
This causes connection failures to the server and failed builds.
Add some extra debugging around the server log and client retry
log messages to give more information for the next time this issue
occurs.
(Bitbake rev: 376a516dc8c96727fd042ada65f803013601ee2d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Bitbake is moving to a minimum python version of 3.8, update OE-Core
to match to make things consistent.
(From OE-Core rev: cc05bc04156122fd6f918191a9cec7bc0392415e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Most of our older distros with python older than 3.8 already need buildtools
tarballs apart from Ubuntu 18.04. 3.8 allows us to fix a few things, tidy
code in places and is widely available or can be obtained with buildtools.
Therefore update our minimum version to 3.8.
(Bitbake rev: 744310f360d2288ac2ef07745abc86852126b5b9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
do_setscene was from a different era before our modern setscene
per task code. It hasn't been used for years so remove some old
obsolete references to it.
(Bitbake rev: ef72282298f7c4db74383c23bb0251dd06d3c6d3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
All siggens in common use should now support multiconfig, drop the
compatibility code.
(Bitbake rev: b36545b4df6d935ed312ff407d4e0474c3ed8d1a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We're now used to using hashes as part of the task hashes and the sstate code
relies on this. The older OEBasic hash approach therefore wouldn't work and
can be removed.
(From OE-Core rev: 3667e589ba16eb261cfd72c2b11429f482c239f6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When obtaining latest upstream versions, the code needs
to check if the existing tarball is in a versioned directory
(e.g. component-name/x.y/component-name-x.y.z.tar.gz) and
if it is, it needs to first obtain the list of all
such versioned directories and then check all of them by going
one step up in the directory hierarchy.
Existing code was returning a correct match when the component
name did not have numbers, e.g. a check on 'source/epiphany/43/'
would return 43, but was stopping too soon when the component
name itself had numbers ('source/libxml2/2.10/' would return libxml2).
This change ensures the last match is taken instead of the first.
Also, adjust the fetcher tests to check that versioned directories
are correctly traversed in this case (e.g. the step to go one level
up is taken and a new tarball is discovered in a different versioned
directory).
(Bitbake rev: b6601be22c6d776327acdcd1fa931400f41ac786)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
largefile was made the default and the distro feature is no longer needed.
Drop the leftovers in poky.
(From meta-yocto rev: c5da2d28ed517fff4a32e3bbad4511a1a4bf19b0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The bitbake git fetcher currently fetches 'refs/*:refs/*', i.e. every
single object in the remote repository. This works poorly with gitlab
and github, which use the remote git repository to track its metadata
like merge requests, CI pipelines and such.
Specifically, gitlab generates refs/merge-requests/*, refs/pipelines/*
and refs/keep-around/* and they all contain massive amount of data that
are useless for the bitbake build purposes. The amount of useless data
can in fact be so massive (e.g. with FDO mesa.git repository) that some
proxies may outright terminate the 'git fetch' connection, and make it
appear as if bitbake got stuck on 'git fetch' with no output.
To avoid fetching all these useless metadata, tweak the git fetcher such
that it only fetches refs/heads/* and refs/tags/* . Avoid using negative
refspecs as those are only available in new git versions.
Per feedback on the ML, Gerrit may push commits outsides of branches or
tags during CI runs, which currently works with the 'nobranch=1' fetcher
parameter. To retain this functionality, keep fetching everything in case
the 'nobranch=1' is present. This still avoids fetching massive amount of
data in the common case, since 'nobranch=1' is rare. Update 'nobranch'
documentation.
Reviewed-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
(Bitbake rev: d32e5b0ec2ab85ffad7e56ac5b3160860b732556)
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In checkstatus() opener.open() is used to check if an artifact is available.
The check fails if the uri contains username password in the format:
"username:password@hostname..". Moreover, the checkstatus function already uses
the username from the "ud" object to craft a header, is username and password is
provided.
This fix ensure the uri in the Requests object used does not contain username as
password.
(Bitbake rev: 88350002d45e0aa85ecd5356da2c8d71e450641e)
Signed-off-by: Kasper Revsbech <kasper.revsbech.ext@siemensgamesa.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We keep seeing server issues where the lockfile is present but we can't
connect to it. Reuse the lockfile debugging code from the server to
dump better information to the console from the client side when we
run into this issue. Whilst not pretty, this might give us a chance
of being able to debug the problems further.
(Bitbake rev: 22685460b5ecb1aeb4ff3436088ecdacb43044d7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
