This allows automated version updates to the recipe,
as mesa-gl.bb no longer has to include the main mesa.bb.
Bump mesa-gl to 20.0.7 at the same time.
(From OE-Core rev: 39aba6948e04f1ee9bb4069be16f68bcfdbbeac4)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Newer versions make use of ustat() which is absent in musl.
(From OE-Core rev: 658d17cce2a83a760f70769cb2fca342b9553458)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This tool can be turned on in busybox which lead into a error during
do_rootfs.
(From OE-Core rev: eb22e7a1190a79fd74ae54f23a13ec4932f41b0d)
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* This reverts commit d9971f5dc8eb7de551fd6f5e058fd24770ef5d78.
* With the missing Subject line fixed in GitApplyTree.prepareCommit()
we should be able to revert, the fix which was trying to help it by
parsing GitApplyTree.patch_line_prefix ("%% original patch:") also
from Subject line, now GitApplyTree.patch_line_prefix should always
end on separate line which is then skipped when copying the lines to
resulting patch, see original commit message from Paul:
lib/oe/patch: fix handling of patches with no header
If a patch applied by a recipe has no header and we turn the recipe's
source into a git tree (when PATCHTOOL = "git" or when using devtool
extract / modify / upgrade), the commit message ends up consisting only
of the original filename marker ("%% original patch: filename.patch").
When we come to do turn the commits back into a set of patches in
extractPatches(), this first line ends up in the "Subject: " part of
the file, but we were ignoring it because the line didn't start with the
marker text. The end result was we weren't able to get the original
patch name. Strip off any "Subject [PATCH x/y]" part before looking for
the marker text to fix.
This caused "devtool modify openssl" followed by "devtool update-recipe
openssl" (without any changes in-between) to remove version-script.patch
because that patch has no header and we weren't able to determine the
original filename.
(From OE-Core rev: d9e56db415d386447a299dd633b10f1eda0dd401)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* also remove the extra blank lines which is often added to patches
when refreshed with devtool (GitApplyTree.patch_line_prefix lines
are ignored when refreshing .patch files, but newly added blank
lines aren't - the leading blank line wasneeded for patches with
just the subject line (to prevent the GitApplyTree.patch_line_prefix
line ending appended to the commit summary), but we can add it
in prepareCommit instead
(From OE-Core rev: c50c0d6144ad290168167ccef948c7b4ffc9665a)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* this was discovered with
$ devtool finish --force-patch-refresh
where it was removing some patches and replacing them with
patch in filename called "patch:"
e.g. this .patch file:
311067d2d8/dynamic-layers/rust-layer/recipes-browser/firefox/firefox/fixes/fix-camera-permission-dialg-doesnot-close.patch
confuses devtool which results to create new .patch file called "patch:"
$ devtool finish --force-patch-refresh firefox meta-browser
NOTE: Starting bitbake server...
WARNING: Host distribution "ubuntu-20.04" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.
Loading cache: 100% |###################################################################################################################################################################################################################################| Time: 0:00:00
Loaded 2480 entries from dependency cache.
Parsing recipes: 100% |#################################################################################################################################################################################################################################| Time: 0:00:00
Parsing of 1718 .bb files complete (1717 cached, 1 parsed). 2480 targets, 68 skipped, 0 masked, 0 errors.
Summary: There was 1 WARNING message shown.
INFO: Updating patch 0001-Bug-1554949-Fix-WebRTC-build-failure-with-newer-linu.patch
...
INFO: Updating patch pre-generated-old-configure.patch
INFO: Adding new patch patch:
INFO: Updating recipe firefox_68.0esr.bb
INFO: Removing file /OE/build/test-oe-build-time/poky/meta-browser/dynamic-layers/rust-layer/recipes-browser/firefox/firefox/fixes/fix-camera-permission-dialg-doesnot-close.patch
INFO: Cleaning sysroot for recipe firefox...
INFO: Leaving source tree /OE/build/test-oe-build-time/poky/build/workspace/sources/firefox as-is; if you no longer need it then please delete it manually
this looked like incorrect parsing of the git format-patch
files exported from workspace/sources (the git format-patch
version of fix-camera-permission-dialg-doesnot-close.patch
starts like this:
$ head 0008-original-patch-fix-camera-permission-dialg-doesnot-c.patch
From 37dfa11961b48024bedcfb9336f49107c9535638 Mon Sep 17 00:00:00 2001
From: Takuro Ashie <ashie@clear-code.com>
Date: Mon, 20 Aug 2018 10:16:20 +0900
Subject: [PATCH 08/34] %% original patch:
fix-camera-permission-dialg-doesnot-close.patch
so first I've modified GitApplyTree.extractPatches() to be able to
parse the original patch name correctly even in this case where subject
is wrapped, but then it still wasn't right, because we ended with
correctly named .patch file, but all we could use for Subject line
was the name of the original .patch file (instead of the Subject
from metadata commit which introduced this .patch files as some other
.patch files get when refreshed with devtool.
In the end the issue happens even sooner in GitApplyTree.prepareCommit()
where it correctly found the Subject from metadata commit, but then
didn't apply it when there weren't any other outlines from patch headers.
(From OE-Core rev: 0a8252f0cb13e3dc16f70b984f9f98b845b163de)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* I see a case where a tarball contains .gitignore and bunch of files
which are normally ignored in git, but still included in the tarball
(e.g. configure script next to configure.ac)
* when devtool is creating a git repo in workspace it won't include these
files from tarball in the initial devtool-base commit, because
git ls-files won't list them
* but then the first .patch file (without git headers) when applied with
GitApplyTree._applypatch() will add all these still ignored files to a
commit which used to only modify some files, because it's using -f:
# Add all files
shellcmd = ["git", "add", "-f", "-A", "."]
output += runcmd(["sh", "-c", " ".join(shellcmd)], self.dir)
at least in this case it would be better to add all ignored files in
the initial devtool-base commit and then --force-patch-refresh will just
include the small modification as before instead of adding unrelated
files, just because they were initially ignored - this behavior will
also match with the do_patch task in the actual build where the
.gitignore is ignored when unpacking some tarball
* my use-case is fixed in setup_git_repo, but similar function is in
devtool upgrade, I've changed it there as well
(From OE-Core rev: 06a24a615549af3550302a56ea08147000a608f3)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The setting is to modify TUNE_PKGARCH which is filled with
TUNE_PKGARCH_64 or TUNE_PKGARCH_32 in arm-arch64.inc
This lets higher up tune files for arm64 SOCs override them if needed,
this can help building multiple armv8 machines with different tunes in
same workspace.
No need to set TUNE_PKGARCH in tune files as it is synthesized from ARMPKGARCH
Add ARMPKGARCH for aarch64 tunes
(From OE-Core rev: 08433cc58abf0cf3e42b22d20870a50287cfb8bc)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The commits 910ffaf5be ("pyelftools: Import from meta-python") and
a96f815c53 ("pycryptodome: Import from meta-python") moved recipes from
meta-python to oe-core. In order for this to be communicated with users,
bump the LAYERVERSION so that meta-python can key of it in its
LAYERDEPENDS.
(From OE-Core rev: 2d503b27e7c88cee9a37c79c4605c77b11f230b6)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In commit 9730f95686b2ac72cf1fa513c555f7c7787e2667
Django 2.2 was enabled.
Django 1.11 was EOL on April 1, 2020
(Bitbake rev: ee15e78c6f9b59c221b1e43973ee4db20c5b443b)
Signed-off-by: Tim Orling <timothy.t.orling@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the '_remove' example in bitbake-user-manual-metadata.xml, there is
no 'jkl' in the original value of FOO2. So remove it from result.
(Bitbake rev: 06b5cf0ab6c6e518ac780d081fab5546334c5c7d)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Note that this patch affects qemuarm AND qemuarm64.
When booting a VM and during operation, the following message
periodically appears:
INIT: Id "hvc0" respawning too fast: disabled for 5 minutes
This is because hvc0 is specified in SERIAL_CONSOLES in qemuarm.conf
and qemuarm64.conf, but it is not in /proc/consoles and
SERIAL_CONSOLES_CHECK is not specified, leaving getty to attempt to
enable hvc0. Add SERIAL_CONSOLES_CHECK to both conf files so that
hvc0 isn't enabled if it hasn't been set there or in local.conf.
(From OE-Core rev: 982b7f98b8423236cc986346379b1bde3694f131)
Signed-off-by: Trevor Gamblin <trevor.gamblin@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
