When follow the instructions of multiconfig from Yocto dev manual that
set in core-image-sato recipe:
do_image[mcdepends] = "multiconfig:x86:arm:core-image-minimal:do_rootfs"
it show too many annoying warnings look like:
| WARNING: Deferring mc:x86:virtual:native:/buildarea6/kkang/poky/meta/recipes-support/libxslt/libxslt_1.1.33.bb:do_populate_sysroot
| after mc:arm: virtual:native:/buildarea6/kkang/poky/meta/recipes-support/libxslt/libxslt_1.1.33.bb:do_populate_sysroot
Treat them as infomations rather than warnings.
(Bitbake rev: cfa307aabf710d79c404a8571b4158b864a94727)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some GStreamer recipes like gstreamer1.0-vaapi already use HTTPS instead
of http. Also, access to http:// is simply redirected by the freedesktop
server to https://, and using HTTPS is anyway generally recommended over
plain HTTP for security reasons. So, normalize the URLs to use HTTPS only.
(From OE-Core rev: 7ca54d025168688b1b612c43c9ed4bc0f2ca4d02)
Signed-off-by: Carlos Rafael Giani <crg7475@mailbox.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* 0001-scaletempo-Advertise-interleaved-layout-in-caps-temp.patch
* headerfix.patch
Removed since these changes are already included in 1.16.1
(From OE-Core rev: f992741666ddc83ccbf3149f1544b95958150620)
Signed-off-by: Carlos Rafael Giani <crg7475@mailbox.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backport patches to fix CVE-2019-6471 and CVE-2018-5743 for bind.
CVE-2019-6471 is fixed by 0001-bind-fix-CVE-2019-6471.patch and the
other 6 patches are for CVE-2018-5743. And backport one more patch to
fix compile error on arm caused by these 6 commits.
(From OE-Core rev: 3c39d4158677b97253df63f23b74c3a9dd5539f6)
(From OE-Core rev: 07a8d013383b622eabfcefec9378c857b5265c05)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drop backports, rebase a couple of patches.
This is the second last release of py 2.x; upstream support ends on
1 January 2020, there will be one final 2.x afterwards.
Note that the only thing that still needs python 2.x in oe-core is
u-boot; when the next u-boot update arrives, we should find out
where the py3 migration is for that component before merging the
update.
(From OE-Core rev: 184b60eb905bb75ecc7a0c29a175e624d8555fac)
(From OE-Core rev: d8cd909e7c073eb6365732e5c906f52933fe2e66)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit 41d225f4a3.
Unfortunately this change broke 'devtool upgrade' functionality,
causing 'devtool finish' to write out an upgraded recipe that no
longer includes the original upstream source in SRC_URI.
(From OE-Core rev: 2d6e55192dba0bf7f6e23e5ab5b3dbc68835bb28)
(From OE-Core rev: 2bb221ee5689f13d44b7452738f5a97baa1815a1)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Commit: d336110b94 boost: update to 1.67.0
dropped the patch that ensured boost doesn't over-ride the architecture flags
set by us resulting in errors:
| build/tmp/work/x86_64_x32-poky-linux-gnux32/boost/1.69.0-r0/recipe-sysroot/usr/include/bits/long-double.h:44:10: fatal error: bits/long-double-64.h: No such file or directory
| #include <bits/long-double-64.h>
| ^~~~~~~~~~~~~~~~~~~~~~~
| compilation terminated.
Remove the relevant part from gcc.jam again to ensure we are passing
them correctly again.
Fixes [YOCTO #13598]
(From OE-Core rev: aad28f42b1c8aa1335c040630ebff4a69be07e35)
(From OE-Core rev: ebbfe23acfbc820ad7b71c95539b5af97a8be49d)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This code used to construct a single SQL statement that fetched the NVD data for
every CVE requested. For recipes such as the kernel where there are over 2000
CVEs to report this can hit the variable count limit and the query fails with
"sqlite3.OperationalError: too many SQL variables". The default limit is 999
variables, but some distributions such as Debian set the default to 250000.
As the NVD table has an index on the ID column, whilst requesting the data
CVE-by-CVE is five times slower when working with 2000 CVEs the absolute time
different is insignificant: 0.05s verses 0.01s on my machine.
(From OE-Core rev: 53d0cc1e9b7190fa66d7ff1c59518f91b0128d99)
(From OE-Core rev: 3ded9a64c95ae02df7562fc69e2af08c150d2452)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A previous optimisation was premature and resulted in false-negatives in the report.
Rewrite the checking algorithm to first get the list of potential CVEs by
vendor:product, then iterate through every matching CPE for that CVE to
determine if the bounds match or not. By doing this in two stages we can know
if we've checked every CPE, instead of accidentally breaking out of the scan too
early.
(From OE-Core rev: d61aff9e22704ad69df1f7ab0f8784f4e7cc0c69)
(From OE-Core rev: 0f42a1d4dbb74ab39e81449cf222302bcc04f7db)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
urllib handles adding proxy handlers if the proxies are set in the environment,
so call bb.utils.export_proxies() to do that and remove the manual setup.
(From OE-Core rev: 6b73004668b3b71c9c38814b79fbb58c893ed434)
(From OE-Core rev: 15f6b4b59805db40df4eff6d5a2809f6f05b66c1)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Create an index on the PRODUCTS table which contains a row for each CPE,
drastically increasing the performance of lookups for a specific CVE.
(From OE-Core rev: b4048b05b3a00d85c40d09961f846eadcebd812e)
(From OE-Core rev: 1b4a524da1532d15eb34a96c5bda5ff2af25a953)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Don't hardcode the database filename, there's a variable for this in
cve-check.bbclass.
(From OE-Core rev: 0d188a9dc4ae64c64cd661e9d9c3841e86f226ab)
(From OE-Core rev: 1c10a3189aad5109f04d1fc208d579225bdd1431)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We already fetch the yearly CVE metadata and check that for updates before
downloading the full data, but we can speed up CVE checking further by only
checking the CVE metadata once an hour.
(From OE-Core rev: 50d898fd360c58fe85460517d965f62b7654771a)
(From OE-Core rev: f9e9107dbe23293eb96e049d7f821d2e33c23f06)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The patch scanner works with patch files in the layer, not in the workdir, so it
doesn't need to unpack.
(From OE-Core rev: 2cba6ada970deb5156e1ba0182f4f372851e3c17)
(From OE-Core rev: 02e6b727bf62858be7dba061879a6d57bd5a725d)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adds an option that can be used to copy the offending packages to a temp
directory for later evaluation. This is useful on the Autobuilder to
investigate failures.
(From OE-Core rev: 91d657a0c4cbb273e1e74d38bfd6b4b05d9b372e)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Older versions break opkg-build when reproducible builds are enabled.
Rather than trying to be selective based on which features are enabled,
lets just make this a minimum version.
(From OE-Core rev: 96f5c7c2f8dda7d47af5398b3463aa25921f5301)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
opkg-build was failing on hosts where tar < 1.28 and reproducibile builds
were enabled but it was doing this silently and generating corrupted
(empty) ipk files. Add a fix for this (submitted upstream).
The fix requires bash but if you're building ipk files this shoudn't be
a problem.
(From OE-Core rev: 5d774331226f967a2d00c9594c4811ee378cd572)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
An ipk with a zero size data.tar file caused opkg to crash with a
double free abort. Add the upstream fixes for this.
(From OE-Core rev: ea1ded0b47e85d039dfad2b59580817bfb335739)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Setscene hard dependencies were not being correctly handled during task migration.
For example, do_package of recipe X might become valid due to hashequiv yet we're
still rebuilding pseudo-native, a harddep of do_package. This would mean
it would try to execute that setscene task despite pseudo not being present.
Fix this by ignoring tasks with failed harddependencies. This does mean
stlightly more rebuilds than is optimal but it avoids build crashes. Ultimately
the new runqueue model can likely better handle these cases than the older codebase
could but that is for another more invasive patch.
(Bitbake rev: 9a1072060350dc2e0eee14a5cc5af20c900f8a6d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Bibake is currently too 'chatty' when hash equivalence is enabled. Fix
this by only printing the log output if a rehash happens and it matches
an sstate object.
Also, pass a summary option to the hash checking function. This was
already changed to a mechanism which allows addition of new parameters
so this should be backwards and forwards compatible.
(Bitbake rev: c5c5d786ca968d0e48002fe8acbcc8a63a954b67)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a hash is reported to the hash server, the stamp written out by the
current task didn't account for any new hash the server may have provided.
Fix this so the correct stamp is written. This means "bitbake X; bitbake X"
no longer rebuilds lots of things when hashequiv is active.
(Bitbake rev: 4299afdd290f9d1c5616598f5fe83c195a64b63c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The server is now restarting when running commands which doesn't make
sense. Only restart if its configuration has changed. This should
potentially fix various memory resident bitbake usages too.
(Bitbake rev: 7c847b01c30fc42cc78244f00fdf5eaa7b5df716)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The key problem is that currently running setscene tasks are not
accounted for when processing task migrations. This means can allow
two of the same task to execute at the same time with unpredictable
effects.
This change allows us to stop doing that and refactor the code slightly
to make it clearer that these conditions don't arrive even with
deferred tasks.
(Bitbake rev: 33ffc2128b1a74fa7179a8341db68cddf402536f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bitbake/lib/bb/fetch2/clearcase.py:148: SyntaxWarning: "is" with a literal. Did you mean "=="?
if command is 'mkview':
bitbake/lib/bb/fetch2/clearcase.py:155: SyntaxWarning: "is" with a literal. Did you mean "=="?
elif command is 'rmview':
bitbake/lib/bb/fetch2/clearcase.py:159: SyntaxWarning: "is" with a literal. Did you mean "=="?
elif command is 'setcs':
Python 3.8 is quite correct and we so mean "==" here, fix it to
avoid the warnings.
(Bitbake rev: 2cccc14304855cb55f339e465f6ba6ed0c69a7ab)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
