Native recipes have been special and they don't have packages generated
from them. The RDEPENDS/RPROVIDES and other runtime package specific
variables can contain important data about dependencies recipes need
though and currently it is required to write this information explicitly
in the native case.
We now delete the packaging tasks for native recipes which removes the
need to clear PACKAGES. The next step to improve the metadata is to
stop clearing it and ensure any entries in these variables are remapped
appropriately. The R* variables were already being processed by the class
extension code but the implementation was suboptimal.
This patch stops clearing PACKAGES and PACKAGES_DYNAMIC and fixes the places
where that caused issues in OE-Core, for example PACKAGES additions in anonymous
python without the "-native" suffix and a case where the included classes
caused a self reference in DEPENDS which would once have been removed by
the previous code.
The implementation uses datastore/parser parameters to ensure that the
variable overrides are not overwritten when calling setVar which is appropriate
for a function as close to the core as this one is.
Some now unneeded code in python3-setuptools is dropped, there are further
changes like this which can follow.
This change was verified with OE-Core by comparing task-depends.dot generated
by "bitbake world -g" before and after the change, the files were identical.
(From OE-Core rev: fd6a007efa7cb45101a66f294af81d9d33bb3fab)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- spirv-headers is provived in a separete receipe, so add it as dependencie
- add a new package spirv-tools-lesspipe that needs bash
- remove unneeded external sources
(From OE-Core rev: 97cab6b9691497841b2ae894e25f83d893c2ee30)
Signed-off-by: Jose Quaresma <quaresma.jose@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drop patches:
* 0001-Fix-the-link-order-of-libglslang-and-libHLSL.patch
is rejected upstream and is not need when glslang as shared libs.
Update pacthes:
* 0001-cmake-de-vendor-libs-and-disable-git-versioning.patch
renamed and refreshed from 0003-cmake-de-vendor-libs-and-disable-git-versioning.patch.
(From OE-Core rev: 496c69d56806a2521bfc51b4de9575637db2ac02)
Signed-off-by: Jose Quaresma <quaresma.jose@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove backported patches and remove the introspection patch as that is
no longer needed.
(From OE-Core rev: 94bc7f8c2442f6627b001f1dd40c0023260b22e8)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We're still seeing reproducibility issues on the autobuilder with this
recipe. I was able to make the output "match" by rebuilding the PCH and
then rebuilding the binary objects, proving the PCH isn't deterministic.
Disable PCH until we can get to the bottom of why that may be.
(From OE-Core rev: 95686432ecb7e411155563643d59a3d5f683937c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is code to remove the prefix CMAKE_SOURCE_DIR from __FILENAME__ paths
used for logging with LOGE() in the code. We need to make this match the value we use
in the debug source remapping from CFLAGS. If we don't, the code is firstly removing
the incorrect prefix and possibly moving outside the string, secondly, it causes a
reproducibility issue depending on the length of path the build happens in.
Add a small patch and configuration to avoid the issue.
(From OE-Core rev: 410dbfd1f82b4862ced6fca88789edf0fd9d65df)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Two of the patches have been applied upstream:
0001-meson-Add-xcb-fixes-to-loader-when-using-x11-and-dri.patch
0005-vc4-use-intmax_t-for-formatted-output-of-timespec-me.patch
The 'surfaceless' platform is now enabled by default, therefore it is no
longer a valid choice. The meson build system is intelligent enough now to
decide if 'drm' needs to be enabled based on whether or not gbm is available.
Therefore 'drm' also is no longer a valid platform choice:
ERROR: Options "drm, surfaceless" are not in allowed choices: "auto, x11, wayland, haiku, android, windows"
RP: Add missing mesa-gl upgrade
(From OE-Core rev: de68fe9268092c0600a81bedfc805eaed9dcb87b)
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit adds the changes of 20.2.2, 20.2.3 and 20.2.4 bug fix
releases.
(From OE-Core rev: 9c39a1360d81264e867242f238f6d14fdb395e96)
Signed-off-by: Fabio Berton <fabio.berton@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Incorrectly set git regex meant we were stuck with a 4 year old
version.
Use tarballs as they contain prebuilt font files; building them
from source requires a bunch of obscure dependencies.
Contains portions of libglyph which are Apache 2.x licensed.
(From OE-Core rev: 4dcde0147ec4d63ab4459dc1e995cea155130e36)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
-License-Update: Copyright year updated to 2020.
Refresh the following patch:
0001-libjpeg-turbo-fix-package_qa-error.patch
(From OE-Core rev: 490fe53f625417494dd63a4fe4dcaa98a3c54eb9)
Signed-off-by: Zang Ruochen <zangrc.fnst@cn.fujitsu.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
PACKAGECONFIG[directfb] already adds directfb to the build
dependencies. But the automatically generated runtime
dependencies do not add the directfb package to the runtime
dependencies. Most likely this happens because libsdl2 does not link
against directfb but uses dlopen() or similar. Thus, the runtime
dependency to directfb needs to be declared explicitly.
(From OE-Core rev: 62d3cbe7c8261c1c875ff6da11572409262aaf02)
Signed-off-by: Mark Jonas <toertel@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
fix error:
| framework/lib/ppc/libframework.a(device.cpp.o): in function `std::__atomic_base<unsigned long long>::load(std::memory_order) const':
| /usr/include/c++/10.2.0/bits/atomic_base.h:426: undefined reference to `__atomic_load_8'
some arch don't have built-in atomic, so need to link it
explicitly
(From OE-Core rev: 65410c5ff4f9c34758d1e2270132c631166e7d1a)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Running the weston compositor as the root user is an insecure default
behavior for OE-core. We can do much better, at least when using
systemd. Change the recipe to create a dedicated "weston" user and start
weston as this user. The systemd service and socket units are no longer
template units, as there were several inconsistencies in the templates.
Instead, there is now a global /run/wayland-0 socket that gets created,
and systemd will start weston on demand when a client connects to that
socket or when attempting to reach graphical.target, whichever comes
first. This also allows downstream users to easily change the behavior
so that weston *only* starts on demand by adding a drop file. Access to
the global socket is controlled by a "wayland" group; any user that is a
member of the group can use the socket to talk to the compositor. This
also satisfies another use case where another systemd service might
start a graphical application that needs to display with weston (e.g. a
single function device in kiosk mode). Finally, the udev rules for
starting weston with the existance of a DRM device have been removed.
Being WantedBy= a graphical target should eliminate the need for this
behavior, and having it present makes it difficult for downstream users
to start weston on demand (having to override the udev rules).
(From OE-Core rev: dd83fb40f76749c6689807afabc63b9d5c2a4065)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
files/0001-xf86drm.c-fix-build-failure.patch
Removed since this is included in 2.4.103.
(From OE-Core rev: 689df7eb86103b59304ceb5b69bf544cc3fe3f6c)
Signed-off-by: Zang Ruochen <zangrc.fnst@cn.fujitsu.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* it was added to weston-init in 72dd74c5d384dbe641cc7c02ecf766ff8d5f555f now world
builds are failing with:
ERROR: Nothing RPROVIDES 'weston-init' (but openembedded-core/meta/recipes-graphics/wayland/weston_9.0.0.bb RDEPENDS on or otherwise requires it)
weston-init was skipped: missing required distro feature 'pam' (not in DISTRO_FEATURES)
NOTE: Runtime target 'weston-init' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['weston-init']
ERROR: Nothing RPROVIDES 'weston-dev' (but openembedded-core/meta/recipes-graphics/wayland/weston_9.0.0.bb RDEPENDS on or otherwise requires it)
No eligible RPROVIDERs exist for 'weston-dev'
NOTE: Runtime target 'weston-dev' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['weston-dev']
ERROR: Nothing RPROVIDES 'weston' (but openembedded-core/meta/recipes-graphics/wayland/weston_9.0.0.bb RDEPENDS on or otherwise requires it)
No eligible RPROVIDERs exist for 'weston'
NOTE: Runtime target 'weston' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['weston']
(From OE-Core rev: 0a882490fe75915c7a119f3498df6750be25f8e0)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
