This recipe ships unversioned libraries so fiddle the intermediate variables
instead of rewriting FILES directly.
(From OE-Core rev: d6d15924a7b3fe668d4c7e88fd4c90b0d580f2ed)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The core emulated by default by qemu-mips(el) just crashes with
illegal instruction when encountering DSP and/or MIPS16e
instructions - we have to specify a CPU that supports the extra
instructions.
This is an issue when generating a rootfs and e.g. running some
of the package postinstall scriptlets.
The patch to qemu to add 24KEc as a CPU has been accepted
upstream, so let's use that CPU here as well as needed.
(From OE-Core rev: 8af17075f56241dd8f3ea86c609adbd73f248218)
Signed-off-by: André Draszik <git@andred.net>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch has been accepted upstream:
http://lists.nongnu.org/archive/html/qemu-devel/2016-07/msg05778.html
(From OE-Core rev: b89bd412a69bfda262ed795e970b362ddbec6c68)
Signed-off-by: André Draszik <git@andred.net>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The patch 0001-fix-for-multijob-build.patch was removed by:
"d437921 screen: upgrade to 4.4.0"
But in fact the fixes is not all in the version 4.4.0, we
still get errors in parallel builds:
| ../screen-4.4.0/screen.h:48:18: fatal error: comm.h: No such file or directory
So rebase the patch and add it back.
(From OE-Core rev: 6cc3aea5ca7faf018fc50f66c7b2aa0e870addff)
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The commit "054ea20 avahi-ui: Build with Gtk+3"
enabled gtk3 and disabled gtk2, which causes failure on
some package depends on gtk2, like gnome-disk-utility
in meta-openembedded/meta-gnome:
| checking for GTK2... yes
| checking for AVAHI_UI... no
| configure: error: Package requirements (avahi-ui >= 0.6.25) were not met:
|
| No package 'avahi-ui' found
The gtk2 and gtk3 feature for avahi-ui is not exclusive, so change
to use PACKAGECONFIG for them so we can easily enable/disable one
of them or both of them as needed.
(From OE-Core rev: bb44ef79c1ea9fb1d2e37978bcf964e62caaf4cd)
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit 29a8c45be2862be02afe2ebbc5c026a42f351990.
A few things wrong with this change:
1. It patches a patch (runtest-2.4.0.patch).
2. It introduces deviations from the desired ptest output format.
3. It discards PASS: lines from the test output; I *want* to see those.
4. The upstream status of "pending" is incorrect; I do not see this
patch on the lttng-dev mailing list (not that it would apply anyway).
(From OE-Core rev: eeb0a912145f8f849d56c04e38616d12ca8be21e)
Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add three tests to verify that the git URL mangling is working the way
it's supposed to. This should prevent us regressing on this again in
future.
(From OE-Core rev: d8d01f462ddbb79cff23b544fcd0ce251f05f8ce)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently when a recipe adds more than one user/group, the
cleansstate task will delete only the first user/group. This
will solve this behavior and delete all users/groups.
[YOCTO #9943]
(From OE-Core rev: da191d5c139a6b400d1b8fe246912b081dd18176)
Signed-off-by: Mariano Lopez <mariano.lopez@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using ${DEBIAN_MIRROR} for SRC_URI doesn't work very well as that will only
contain releases that are currently in Debian, so currently doesn't contain
1.18.7 as unstable has moved on to 1.18.9.
So, move all of SRC_URI to the .bb so it can use snapshot.debian.org instead,
and set UPSTREAM_CHECK_URI to ${DEBIAN_MIRROR} so upstream release checking
continues to work.
(From OE-Core rev: b32d430c3c7dccf3a8d06ab492d648893a05950f)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since this recipe doesn't use a SCM the SRCREV is unneeded (and
inaccurate).
(From OE-Core rev: 7635748f9bf2de75e94222ff286b9d02e85b2dfe)
Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This recipe uses some convoluted methods to ensure the build is using the right
flags but they don't appear to be needed anymore.
No need to prepend HOST_CC_ARCH/TOOLCHAIN_OPTIONS via CFLAGS as the Makefile
picks up CC from the environment and that includes these options.
No need to append the default CFLAGS as their special options are actually in
CPPFLAGS.
(From OE-Core rev: 2230e5f7bf7e6dc747ada74477d5a72905d8d80b)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you supplied an empty file to patch_recipe() (or an empty list to
patch_recipe_lines()) then the result was IndexError because the code
checking to see if it needed to add an extra line of padding didn't
check to see if there were in fact any lines before trying to access the
last line.
Fixes [YOCTO #9972].
(From OE-Core rev: 92a73e870478ddb2a2d137e3fff28828809bec2e)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I got fed up with seeing items dance around in sstate-package-sizes.txt
in the buildhistory git repo simply because they have the same size.
Let's sort the list first by size and then also by name to ensure items
with the same size are deterministically sorted.
(From OE-Core rev: 7340c1ea677731d21351d47d935d9de7d7e2eda5)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add SDK_INCLUDE_PKGDATA and SDK_INCLUDE_TOOLCHAIN to the variables that
we put into sdk-info.txt
(From OE-Core rev: 4bf5be6a1fc39f367bbb59e1787cb55e7b5835ae)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If SDK_EXT_TYPE is set to "full" then we really ought to be shipping
everything that is expected to be in the SDK, and that includes gdb
(it's already referred to by the environment setup script if nothing
else). This is implemented by using the SDK_INCLUDE_TOOLCHAIN
functionality I just added, since the only material thing that adds on
top of a full SDK is gdb and we should always have the rest of it in a
full SDK anyway.
Fixes [YOCTO #9850].
(From OE-Core rev: 9872dcc25c5cdfb99bda197db08476085f8c7ecc)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use the new oe-check-sstate to filter the sstate artifacts shipped with
the extensible SDK by effectively running bitbake within the produced
eSDK and and getting it to tell us which tasks it will restore from
sstate. This has several benefits:
1) We drop the *-initial artifacts from the minimal + toolchain eSDK.
This still leaves us with a reasonably large SDK for this
configuration, however it does pave the way for future reductions
since we are actually filtering by what will be expected to be there
on install rather than hoping that whatever cuts we make will match.
2) We verify bitbake's basic operation within the eSDK, i.e. that
we haven't messed up the configuration
3) We verify that the sstate artifacts we expect to be present are
present (at least in the sstate cache for the build producing the
eSDK). Outside deletion of sstate artifacts has been a problem up to
now, and this should at least catch that earlier i.e. during the
build rather than when someone tries to install the eSDK.
This does add a couple of minutes to the do_populate_sdk_ext time, but
it seems like the most appropriate way to handle this.
Should mostly address [YOCTO #9083] and [YOCTO #9626].
(From OE-Core rev: 4b7b48fcb9b39fccf8222650c2608325df2a4507)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we're to completely replace the standard SDK with the extensible SDK,
we need to be able to provide the standard toolchain on install without
doing anything other than installing it, so that you can install the SDK
and then point your IDE at it. This is particularly applicable to the
minimal SDK which normally installs nothing by default.
NOTE: enabling this option currently adds ~280MB to the size of the
minimal eSDK installer. If we need to reduce this further we would have
to look at adjusting the dependencies and/or the sstate_depvalid()
function in sstate.bbclass which eliminates dependencies, or look at
reducing the size of the artifacts themselves.
Implements [YOCTO #9751].
(From OE-Core rev: ed0d8ed72370df694f720cc13897493478dc1de9)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a meta-recipe to bring the toolchain into the extensible SDK. This
was modelled on meta-ide-support but some adjustments were needed to the
dependency validation function in sstate.bbclass to ensure that all of
the toolchain gets installed into the sysroot. With this, after
installing a minimal eSDK you only need to run the following after
sourcing the environment setup script to get the toolchain:
devtool sdk-install meta-extsdk-toolchain
Addresses [YOCTO #9257].
(From OE-Core rev: 8110806b1b5534ae830a4fdd1a5293c86a712d0b)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We don't absolutely need this - it doesn't change the default
behaviour, but it seems to me we have a convention to set default values
so we should add one here.
(From OE-Core rev: 4c734df1df3c19b0dabb9da5b4dc86b966a0d71c)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of using a directory in the layer as the GPG home and carefully deleting
the right files from it, use tempfile to create a temporary directory which will
be cleaned up for us.
Also change the public/secret key variables to be absolute paths as they're
always used as absolute paths.
(From OE-Core rev: d4a5b5d11c6d7d5aba5f2eb88db091c1b98ef87c)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Do not set default values of KDUMP_CMDLINE and KDUMP_KIMAGE, and leave
them set by configure file since they are different for different
architectures. Take KDUMP_KIMAGE kdump kernel image for example:
x86 is bzImage
mips64 is vmlinux
ppc is uImage
arm is zImage
(From OE-Core rev: 05dcb054fcd0c80bb09612c3e15b6b1f0487aae8)
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
1.2.7 -> 1.3.0
(From OE-Core rev: acff48731ea19c11768fed076d696fd1cb0bbbf0)
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
5.40 -> 5.41
(From OE-Core rev: 633e73fb780da76e5025483310c3ca7eb5f78a26)
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Take the dash compatible IPv6 link-local address test from the Debian
version of dhclient-script.
Note that although "echo -e" in the OE version of dhclient-script is
technically bash specific too, it is supported by Busybox echo when
Busybox is configured with CONFIG_FEATURE_FANCY_ECHO enabled (which
is the default in the OE Busybox defconfig) therefore leave as-is.
(From OE-Core rev: acd7b33d136fac52e1da7ce1bb3edd2a938b1b6f)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Integrate the commit from a70c568b90
to fix a bug which causes the 'netstat -a' to print "[UNKNOWN]" in case of
DNS problem instead of IPv6 address.
(From OE-Core rev: e99a7220bbc2d605200d5005ba40bf45f6f8dcf5)
Signed-off-by: Jianchuan Wang <jianchuan.wang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix the floating dependency on polkit by providing a PACKAGECONFIG
option. Then, package the newly created files appropriately.
[YOCTO #9987]
(From OE-Core rev: a1ecd168b092a0cc7322431913fd1f42cfa9a37e)
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bitbake rev 67a7b8b02 "build: don't use $B as the default cwd for
functions" (included in current bitbake master) breaks the assumption
that do_bundle_initramfs runs inside the build directory.
This causes kernel_do_compile() as called from within
do_bundle_initramfs() to fail, as the former is not being executed
from the correct directory anymore. (Note that kernel_do_compile()
as called from bitbake directly doesn't suffer from that problem,
as it inherits the workdir from base_do_compile() in that case.)
Set workdir explicitly.
(From OE-Core rev: 4455da22a151c2ac006af63cbd39779b21b12580)
Signed-off-by: André Draszik <git@andred.net>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The replace() method of the python string class doesn't replace
in-place, then the var KERNEL_IMAGETYPE_FOR_MAKE doesn't be updated as
design.
(From OE-Core rev: 392fc3cd276d5029314c7158245bc65dd82279cd)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
musl contains hand-written assembly which is not compatible with
the MIPS16e mode.
(From OE-Core rev: dbbd58cb64b12cb4dc816425eee59c56cd46301f)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
tar's --no-recursion flag only applies to files mentioned after the
flag, which made it a no-op in this invocation of tar, because it was at
the end of the command line.
This is simple to verify with GNU tar 1.29:
| $ mkdir foo
| $ mkdir foo/dir
| $ touch foo/dir/file
| $ tar -cf - foo --no-recursion | tar t
| foo/
| foo/dir/
| foo/dir/file
| $ tar -cf - --no-recursion foo | tar t
| foo/
Modify the code so that it actually does what the comment says by moving
the flag in front of the --files-from argument.
(From OE-Core rev: d45f5e71fef5ffbd4408f69c5c179dc71a3eb452)
Signed-off-by: Clemens Lang <clemens.lang@bmw-carit.de>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
clang cross compiler fails to detect gold linker from
cross-binutils, instead it defaults to ld.gold from build
host, lets disable using gold when clang is active to avoid
this issue
(From OE-Core rev: 2a535deb4e080f464db1ffc40dfc53235fa13874)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Only check that ${S} actually exists if there was something in ${SRC_URI} to
fetch, the argument being that if SRC_URI is empty the the recipe won't be using
${S} at all.
In general recipes that have no sources can remove the unpack task, but
expecting all recipes to do this relatively advanced operation isn't realistic.
(From OE-Core rev: 8cba511ab6ea557fab9f7838dfe1fc8284bbdd68)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
oe.utils.getstatusoutput() is a wrapper for subprocess.getstatusoutput() which
uses Universal Newlines, so the output is a str() not bytes().
(From OE-Core rev: ce24d4c3632b71939ad198268a900ee823a89b27)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
RPMv5 has removed support for _RPMVSF_NOSIGNATURES,
the flag can be replaced with a flags set:
"RPMVSF_NODSAHEADER|RPMVSF_NORSAHEADER|RPMVSF_NODSA
RPMVSF_NORSA"
(From OE-Core rev: 5c0c1b8a64643ad7130b17b5dfce9cecffa6d962)
Signed-off-by: Haiqing Bai <Haiqing.Bai@windriver.com>
Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After openssl disabled DES, openssh fails to build
for some DES codes are not wrapped in conditional
compile statement "#ifndef OPENSSL_NO_DES" and "#endif".
(From OE-Core rev: cd9c62461e837967dd29a532d32990c23350acf8)
Signed-off-by: Haiqing Bai <Haiqing.Bai@windriver.com>
Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A recipes can generate several rpms such as a.rpm, a-dev.rpm, a-dbg.rpm,
when update one of them in the repo, we'd better update all of them,
otherwise, there might be a-dev.r0.1.rpm and a-dbg.r0.3.rpm in the repo,
which looks strange.
(From OE-Core rev: 2a7f203dbe4fda5dba9137503e93669392719aba)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* fix for python3
iteritems() -> items()
* Return immediately for native and cross.
* Remove the usage of __BBDELTASKS, there is no such var in bitbake.
(From OE-Core rev: ccfc13adedd97f57024420639053080e047529dc)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When a dependency causes a recipe to effectively be rebuilt, its output
may in fact not change; but new packages (with an increased PR value, if
using the PR server) will be generated nonetheless. There's no practical
way for us to predict whether or not this is going to be the case based
solely on the inputs, but we can compare the package output and see if
that is materially different and based upon that decide to replace the
old package with the new one.
This class effectively intercepts packages as they are written out by
do_package_write_*, causing them to be written into a different
directory where we can compare them to whatever older packages might
be in the "real" package feed directory, and avoid copying the new
package to the feed if it has not materially changed. We use
build-compare to do the package comparison.
(From OE-Core rev: cc8b1a93912f830e605e6249c446b3764e550863)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The dict.fromkeys() creates a dict without order, there might be a
problem when build the same recipe again, for example:
- First build of make:
Provides: es-translation, make-locale
- Second build of acl:
Provides: make-locale, es-translation
They are exactly the same Provides, but tools like "diff" doesn't think
so. Sort RPROVIDES will fix the problem.
(From OE-Core rev: 3506172d7d9f8d92362b6ebb75582b7c3e662dae)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* The deb and ipk's depends version string is like:
Depends: libc6 (>= 2.24)
Update trim_release_old and trim_release_new to match the bracket in
the end ")".
* The deb's data tarball now is .tar.xz, and ipk's is .tar.gz.
* Update adjust_controlfile() to make ituse trim_release_old and
trim_release_new.
(From OE-Core rev: c92152e521a9f96a741eccd4a4bf5ddfbd59a7ae)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Fixed checking for named pipe
* Return at once when archives are the same
* Fix for type "directory"
(From OE-Core rev: e3245747342860da44fcbb49ac68b8b33e5b43a3)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The rpm tool is a heavy process, pkg-diff.sh ran 16 (or 17 for kernel)
"rpm -qp" times when the pkgs are identical, now we only run
"rpm -qp --qf <all we need>" twice (one is for old pkg, and one is for
new), save the results to spec_old and spec_new, then use sed command to
get what we need later, this can make it 75% faster when the pkgs are
identical. Here is the rough data on my host Ubuntu 14.04.4, 32 cores
CPU and 128G mem:
* When the pkgs are identical:
- Before the patch: 1s
- After the patch: 0.26s
I compare the whole spec firstly, and return 0 if they are the same,
or go on checking one by one if not, without this, it would be 0.46s,
the gain is great when there are lot of packages, usually, we have
more than 10,000 rpms to compare.
* When the pkgs are different:
That depends on where is the different, if the different is at the
comparing rpmtags stage:
- Before the patch: 0.26s
- After the patch: 0.29s
Increased 0.03s, but if the different is happend later than comparing
rpmtags, it will save time.
(From OE-Core rev: 71eee4adbcda1d9e75cbce58045d03ea12432431)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The command like:
rpm -qp --nodigest --nosignature --qf '<foo> [%{REQUIRENAME}\n]\n'
^^space
The space will be printed, and will impact the check result, so remove it.
(From OE-Core rev: 79c574979f64f2dbe8ca05774446de21a53b3a87)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
OE-core uses rpm's --nosignature, but it never worked:
self._invoke_smart('config --set rpm-check-signatures=false')
Now fix it with:
* Define SUPPORT_NOSIGNATURES to 1 in system.h
* !QVA_ISSET(qva->qva_flags, SIGNATURE) -> QVA_ISSET(qva->qva_flags, SIGNATURE),
otherwise, when use --nosignature would read database and verify
signature, this is not expected.
This can fix some race issues, for example, when more than one process
are querying rpm file with "rpm -qp --nosignature", they may hang up
because of race issues (the processes are trying to get RW/RD lock on
the database, but they shouldn't read the database at all since -qp and
--nosignature are used).
(From OE-Core rev: 038c09d6ab9581030efdc16aa1b96972970eeaab)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Don't modify an OrderedDict while walking its keys.
(From OE-Core rev: eb7f08c4c01313afc8350200eeb63daefde8a6f6)
Signed-off-by: Matt Madison <matt@madison.systems>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ross Burton
André Draszik
André Draszik
Jackie Huang
Nathan Lynch
Paul Eggleton
Mariano Lopez
Roy Li
Maxin B. John
Andre McCurdy
Shan Hai
Khem Raj
Kai Kang
Clemens Lang
mingli.yu@windriver.com
Robert Yang
Matt Madison