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: ff9ec19b02650a3ae230e4d1bdc99ec686cc4c81)
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: aa17a8096263934f5c1877f3ef749df595486a9c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the reproducible_build class is inherited then there may be a
"source-date-epoch" subdirectory in a fetched source tree; devtool
upgrade was not expecting that in the upgraded source. Take a small
snippet of code from recipetool create which already handles this,
and make it a shared function that can be used in both places.
Additionally, fix an assumption that the source is always in a
subdirectory in the cleanup code that blocked debugging this.
[YOCTO #13635]
(From OE-Core rev: 0d642861cd9cf034b8d4951433980addc215d4fd)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This should be no longer needed. if needed then meta-clang might be
better suited
(From OE-Core rev: ad9dd755646fdb42b88440e9464f1d94e244c316)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There was a regression in this functionality that went unnoticed
due to lack of tests.
(From OE-Core rev: a75e4eceb703b2b13ddd4ba3dea3a86af0b0a9eb)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.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)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove obsolete Python 2 code, and use convenience methods for neatness.
(From OE-Core rev: f19253cc9e70c974a8e21a142086c13d7cde04ff)
Signed-off-by: Ross Burton <ross.burton@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)
Signed-off-by: Ross Burton <ross.burton@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)
Signed-off-by: Ross Burton <ross.burton@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)
Signed-off-by: Ross Burton <ross.burton@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)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As upstream has released a new stable version,
the exception is no longer needed.
(From OE-Core rev: fa99c061275cd96cf375ff60d1c73a6e818dca25)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.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)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.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)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The extra diretory created by reproducibile_builds was confusing recipetool
and hence devtool. Ignore this directory to restore the correct behaviour and
allow it to work with the class.
(From OE-Core rev: 188ba30ef290efab6d5a9b95fba8e991b779ab33)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
inherits can be unset resulting in:
UnboundLocalError: local variable 'inherits' referenced before assignment
which can mask real errors. Avoid this.
(From OE-Core rev: 29a0502e101ed0667e960f9f8591b0a2d60a4bcb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a native recipe so won't be installed as root.
If the string 'root' is part of the username then the install script
can get tricked into thinking we are root (regardless of the actual
uid or permissions) resulting in attempts to run chown/chgrp
inappropriately.
(From OE-Core rev: 5db7b80140410cd3c164e4522dc87df92fac93b0)
Signed-off-by: Paul Barker <paul@betafive.co.uk>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
done as part of IncompatibleLicensePerImageTests
(From OE-Core rev: b6e66d388001cdbb833a18056781f69a6f8c82fb)
Signed-off-by: Armin Kuster <akuster808@gmail.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)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upgrade mesa and mesa-gl to 19.2.4.
The license hash change was a trivial new line removal.
The glx-tls option was removed as it isn't included in the meson.build
file. It has been replaced with 'use-elf-tls' instead.
I have backported the asm removal as an attempt to fix the musl build
issue.
(From OE-Core rev: 82c2acc1f658f039becac04aa3dae696418bd1de)
Signed-off-by: Alistair Francis <alistair@alistair23.me>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
selftest to make sure wic rm with -r flag for ext partition
could remove directory and all its content.
(From OE-Core rev: d7ccbb393a71501424b7c0d4c1d78e4bac1ecccf)
Signed-off-by: Chee Yang Lee <chee.yang.lee@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
wic currently unable to remove non-empty directory in ext* partition.
enable wic rm to remove non-empty directory and all the sub-content
with -r flag.
update help documents for 'wic rm'.
[YOCTO #12404]
(From OE-Core rev: 5cb7a329d0aaac8fe5328eb2001692c540aa5ade)
Signed-off-by: Chee Yang Lee <chee.yang.lee@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In 50-systemd-user.sh which is packaged to sub-package
${PN}-xorg-xinitrc, it exports environment variables DISPLAY and
XAUTHORITY to systemd. It fails to start systemd services which require
these environment variables such as thunar.service:
root@qemux86-64:~# systemctl --user status thunar
● thunar.service - Thunar file manager
Loaded: loaded (/usr/lib/systemd/user/thunar.service; disabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:Thunar(1)
Nov 14 07:47:29 qemux86-64 systemd[352]: Starting Thunar file manager...
Nov 14 07:47:29 qemux86-64 Thunar[873]: cannot open display:
Nov 14 07:47:29 qemux86-64 systemd[352]: thunar.service: Main process exited, code=exited, status=1/FAILURE
Nov 14 07:47:29 qemux86-64 systemd[352]: thunar.service: Failed with result 'exit-code'.
Nov 14 07:47:29 qemux86-64 systemd[352]: Failed to start Thunar file manager.
It is not convenient to make all such kind of packages require package
${PN}-xorg-xinitrc, so remove the sub-package and merge the only file
provided by it to main package.
No recipe depends on ${PN}-xorg-xinitrc in oe-core and meta-openembedded
now, so no need to set rprovides for it.
(From OE-Core rev: 9b7d65aa52171cb559cc12ca3fdeaee54b9022c1)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Besides checking DISTRO_FEATURES for required or conflicting features,
being able to check MACHINE_FEATURES and/or COMBINED_FEATURES may also
be useful at times.
Temporarily support the old class name with a warning about future
deprecation.
(From OE-Core rev: 5f4875b950ce199e91f99c8e945a0c709166dc14)
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This should have been removed together with expanded_data in commit
e3694e73 (cooker/command: Drop expanded_data).
(Bitbake rev: 33197db8abf82be240d7c1c5c9d2484a08a90849)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With PRSERV_HOST = "localhost:0", this message would occasionally pop up
during the initial cache read:
WARNING: /home/matic/ambayocto/poky/bitbake/lib/bb/cache.py:446: ResourceWarning: unclosed <socket.socket fd=10, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 45655)>
value = pickled.load()
The file location stated is irrelevant; it just happens to be wherever
CPython decides to run the garbage collector. The issue is that after we
fork off a PRServer, self.socket is also duplicated. The parent side of
it also needs to be closed.
(Bitbake rev: c45b0140c37f2d68c4fa08cd17f0321b8d6524a8)
Signed-off-by: Gavin Li <gavin@matician.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some installation rules have been seen to run chgrp for native recipes
which leads to 'Operation not permitted' errors. To prevent this we
need a chgrp intercept script to go with the existing chown intercept.
(From OE-Core rev: dfb3b566412fb704c5ce67c2dec74c5b1a20921f)
Signed-off-by: Paul Barker <paul@betafive.co.uk>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Richard Purdie
Paul Eggleton
Anuj Mittal
Khem Raj
Alexander Kanavin
Ross Burton
Adrian Bunk
Paul Barker
Armin Kuster
Alistair Francis
Chee Yang Lee
Kai Kang
Denys Dmytriyenko
Peter Kjellerstedt
Gavin Li