Fixes [YOCTO #8584]
Made some edits to tighten this down and make it more efficient.
(From yocto-docs rev: d5a37b77fa5c8df766248849601ca229502bb4ab)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add patches to fix error:
/
| ERROR: oe_runmake failed
| config.status: creating pcap-config.tmp
| mv pcap-config.tmp pcap-config
| chmod a+x pcap-config
| ../libpcap-1.8.1/gencode.c: In function 'pcap_compile':
| ../libpcap-1.8.1/gencode.c:693:8: error: 'compiler_state_t
| {aka struct _compiler_state}' has no member named 'ai'
| cstate.ai = NULL;
| ^
| ../libpcap-1.8.1/gencode.c: In function 'gen_gateway':
| ../libpcap-1.8.1/gencode.c:4914:13: error: 'cstate' undeclared
| (first use in this function)
| bpf_error(cstate, "direction applied to 'gateway'");
| ^~~~~~
| ../libpcap-1.8.1/gencode.c:4914:13: note: each undeclared identifier is
| reported only once for each function it appears in
\
Patches were submitted to upstream [1]
[1] https://github.com/the-tcpdump-group/libpcap/pull/541
(From OE-Core rev: 9f1fe76727e98e58fc9e46ea2b49cf5c0cb48e6c)
Signed-off-by: Fabio Berton <fabio.berton@ossystems.com.br>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
New major release with OpenGL 4.4 support. Dependency on libudev has
been removed.
* Rebase replace_glibc_check_with_linux.patch
* Add patch to find native wayland-scanner
* Add PACKAGECONFIG[osmesa], disabled by default
* package osmesa header correctly
(From OE-Core rev: be60ffcbbdcd370f9d367db887d31a8ccc6b2519)
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In previous implementation, a UnicodeDecodeError exception will be
raised if multi-byte encoded characters are printed by the subprocess.
As an example, the following command will fail in an en_US.UTF-8
environment because wget quotes its saving destination with '‘'(0xE2
0x80 0x98), while just the first byte is provided for decoding:
devtool add recipe http://example.com/source.tar.xz
The patch fixes the issue by avoiding such kind of incomplete decoding.
(From OE-Core rev: 1875ea92546d23abcab1b40b562477a0016f712d)
Signed-off-by: Jiajie Hu <jiajie.hu@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
CVE-2016-3632 libtiff: The _TIFFVGetField function in tif_dirinfo.c in
LibTIFF 4.0.6 and earlier allows remote attackers to cause a denial of
service (out-of-bounds write) or execute arbitrary code via a crafted
TIFF image.
External References:
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-3632http://bugzilla.maptools.org/show_bug.cgi?id=2549https://bugzilla.redhat.com/show_bug.cgi?id=1325095
The patch is from RHEL7.
(From OE-Core rev: 9206c86239717718be840a32724fd1c190929370)
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When build nxp-ls10xx which enable hard-float, it try to force soft-float:
| checking if compiling with clang... no
| checking for options to compile assembly...
| checking whether -freg-struct-return works... yes
| checking for options to get soft-float... no
| configure: error: could not force soft-float
Set COMPATIBLE_HOST_armv7ve to null to skip the build.
(From OE-Core rev: 2758f03cc380990265b0bc139841d6735e0afd8d)
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Both python-scons and python-scons-native need to be upgraded to latest
upstream version.
This change was tested using qemux86 with core-image-sato.
(From OE-Core rev: b3dc1eb3baf54a313a9de03700d57f592bbd73b8)
Signed-off-by: Jose Lamego <jose.a.lamego@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
python-pexpect needs to be upgraded to latest upstream version.
This change was tested using qemux86 with core-image-sato
(From OE-Core rev: 3778171260e02a1054790418b5117db587315321)
Signed-off-by: Jose Lamego <jose.a.lamego@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Both python-mako and python3-mako need to be upgraded to latest upstream
version.
This change was tested using qemux86 with core-image-sato.
(From OE-Core rev: 7828fd75ca8bf3480141237ba300d01a81634b91)
Signed-off-by: Jose Lamego <jose.a.lamego@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Both python-git and python3-git need to be upgraded to latest upstream
version.
This change was tested using qemux86 with core-image-sato.
(From OE-Core rev: e5d8b008d5a1385097a2ac642b8daf8940a899a6)
Signed-off-by: Jose Lamego <jose.a.lamego@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It is a simultaneous upgrade for python 2 and 3 over numpy module.
(From OE-Core rev: 76cfe4d9ba18249376d7391e4f416b5e7c008e8d)
Signed-off-by: Edwin Plauchu <edwin.plauchu.camacho@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This extends the RPROVIDES list to include:
- python3-datetime-native
- python3-enum-native
- python3-terminal-native
(From OE-Core rev: 462ccb35a5de32b52ddb733d1868df6ac5426f20)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Bobby Bingham (2):
treat null vdso base same as missing
add s390x port
Rich Felker (2):
generalize ELF hash table types not to assume 32-bit entries
work around gdb issues recognizing sigreturn trampoline on x86_64
(From OE-Core rev: 39829ef1b8bba3499255c59a4b9713e68a33ddc1)
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>
Remove plan9 related stuff as they are useless for linux systems.
(From OE-Core rev: f0f11d868bbf02ffc8352e77c075de0577c2746e)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Mount nfs directory would fail if no specific nfsvers:
mount -t nfs IP:/foo/bar/ /mnt/
mount.nfs: an incorrect mount option was specified
mount.nfs currently expects mount(2) to fail with EPROTONOSUPPORT if
the kernel doesn't understand the requested NFS version.
Unfortunately if the requested minor is not known to the kernel
it returns -EINVAL.
Backport patch from nfs-utils-1.3.4 to fix this issue.
(From OE-Core rev: 332596628697d28ae6e8c2271c9658aaf5e54796)
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is a carry propagating bug in the Broadwell-specific Montgomery
multiplication procedure that handles input lengths divisible by, but
longer than 256 bits.
External References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-7055https://www.openssl.org/news/secadv/20161110.txt
Patch from:
57c4b9f6a2
(From OE-Core rev: 07cfa9e2bceb07f3baf40681f8c57f4d3da0aee5)
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was already whitelisted, but the 4.8 kernel changed the error
message, causing it to get caught by parselogs again.
Fixes [YOCTO #10494].
(From OE-Core rev: e1bad14231115f3b1a2bf844ef5b2022c648b55d)
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use SHA256 as default digest for OpenSSL instead of MD5.
CVE: CVE-2004-2761
The MD5 Message-Digest Algorithm is not collision resistant,
which makes it easier for context-dependent attackers to
conduct spoofing attacks, as demonstrated by attacks on the
use of MD5 in the signature algorithm of an X.509 certificate.
Upstream-Status: Backport
Backport from OpenSSL 2.0 to OpenSSL 1.0.2
Commit f8547f62c212837dbf44fb7e2755e5774a59a57b
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(From OE-Core rev: f924428cf0c22a0b62769f8f31f11f173f25014f)
Signed-off-by: Zhang Xiao <xiao.zhang@windriver.com>
Signed-off-by: T.O. Radzy Radzykewycz <radzy@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some rolling release distros, such as Arch Linux, don't include a
VERSION_ID field in their os-release file.
Change release_dict_osr() to better handle this optional field
being absent.
Further improve the resilience of the release_dict_*() methods by
always returning a dict and using dict.get() in distro_identifier()
to supply a default, empty string, value when then key is missing.
(From OE-Core rev: e36066dcc3b56cac1c695370ea178b566c0ebfd6)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are many more stats on buildstats that 'Elapsed time', so make the script
more flexible to support all stats. Some cmd line examples:
$ buildstats.sh -s 'utime'
Buildstats' data covers proc's stats in different areas, including CPU times,
IO, program system resources and child program system resources. In order
to print values on each of these sets from command line, one can use the
following:
$ buildstats.sh -H -s 'TIME' | less
$ buildstats.sh -H -s 'IO' | less
and 'RUSAGE' and 'CHILD_RUSAGE' for program and program's child system
resources.
(From OE-Core rev: 81479b191287ccbf4cf94fa2d0ad46813091bca1)
Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
All lines except one (the one containing the 'Elapsed Time') follows the format
'stat: value'. Fix that so post parsing the stats is simpler.
(From OE-Core rev: 47dfd172754440a7ab28eb1b59d9bd484cdad22a)
Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The hello-mod recipe is unusual in that it has only local files in
SRC_URI and builds these out of ${WORKDIR}. When you use devtool modify
on it, devtool puts all of those files in an "oe-local-files"
subdirectory of the source tree, which is not ${S} (or ${B}) any more
and thus building the recipe afterwards fails. It's a bit of a hack, but
symlink the files in oe-local-files into the source tree (and commit the
symlinks with an ignored commit so that the repo is clean) to work
around the problem. We only do this at time of extraction, so any files
added to or removed from oe-local-files after that won't be handled, but
I think there's a limit to how far we should go to support these kinds
of recipes - ultimately they are anomalies.
I initially tried a hacky workaround where I set effectively set B =
"${WORKDIR}" and that allowed it to build, but other things such as the
LIC_FILES_CHKSUM checks still broke because they expected to find files
in ${S}. Another hack where I set the sourcetree to point to the
oe-local-files subdirectory works for hello-mod but not for makedevs
since whilst that is similar, unlike hello-mod it does in fact have
files in the source tree (since it has a patch that adds COPYING) and
thus the same issue occurred.
Also tweak one of the tests that tries devtool modify / update-recipe on
the makedevs recipe to try building it since that would have caught this
issue.
Fixes [YOCTO #10616].
(From OE-Core rev: 857c06d6a1d161bf5a01311d07758bd4241929a3)
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>
A FOSSology related variable was renamed from FOSS_COPRYIGHT to
FOSS_NO_COPYRIGHT, but the comment block describing the variable
in licenses.conf was missed.
Besides fixing this, this change also removes a redundant comment
about where the variable is defined (it's right there! ;-)).
(From OE-Core rev: 5f08d4ea1b4ddf04d7f1d8aa38c0dac9b1af44bc)
Signed-off-by: Olof Johansson <olofjn@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* The webkitgtk package should recommend the ca-certificates one,
because any program usign webkit (and not only epiphany) would
expect that the CAs certificates are available and that https
validation works as expected.
* For example, webkitgtk includes a MiniBrowser program that would
fail to proper verify https sites if the ca-certificate package
is not installed
* Instead of making each one of the webkitgtk consumers care about
the certificate package, do this in webkit itself.
(From OE-Core rev: fe694f9713595fc5f83c47111f03fc8a0a222f14)
Signed-off-by: Carlos Alberto Lopez Perez <clopez@igalia.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The .deb import feature did not import postinst, postrm, preinst, or
prerm functions. This change checks to see if those files exist, and
if so, adds the appropriate functions.
[ YOCTO #10421 ]
(From OE-Core rev: ebb73aa6ad920bfd6a23f8c20105d6bcf07dd3d5)
Signed-off-by: Stephano Cetola <stephano.cetola@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For now, the rpm macro for multilib is not installed correctly. For
example, in x86-64 lib32 situation, the macro is installed under
tmp/work/x86-pokymllib32-linux/rpm/5.4.16-r0/image/usr/lib/rpm/poky/i686-linux/.
The directory is even not under WORKDIR. And it will of course not be
packaged.
We need to save necessary values before updating the localdata and restore
them so that the macros could be installed into the correct directory.
(From OE-Core rev: 40e92de46489bdab0af48fedc46c0d153355f15c)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Replicate bitbake and eforce en_US.UTF-8 locale so that ouptut of locale-aware
tools remains stable.
(From OE-Core rev: 17cd2cb99d3610fd77595ff116b2168188c250cd)
Signed-off-by: Maciej Borzecki <maciej.borzecki@rndity.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When attempting to run devshell, if no terminal is available, the
error being thrown was not very specific. This adds a list of
commands that failed, informing the user of what they can install to
fix the error.
[ YOCTO #10472]
(From OE-Core rev: c077f4aab2fc956408d4ad45c4e2e2ea6e480624)
Signed-off-by: Stephano Cetola <stephano.cetola@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently systemd depends on systemd-container due to a dangling
symlink deployed with systemd.
Move the symlink to systemd-container.
| DEBUG: systemd contains dangling link /lib/systemd/system/systemd-machined.service
| DEBUG: target found in systemd-container
(From OE-Core rev: e12912ac7484654c201d167831b302a821e14972)
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The old code:
network_enabled = not d.getVar('BB_NO_NETWORK', True)
It is True only when BB_NO_NETWORK is not set (None),
but BB_NO_NETWORK = "0" should also be True while "1" means no network,
"0" means need network in a normal case.
(From OE-Core rev: 3d8db6cb992f96023a0486f64fe6b0f1ead04184)
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>
This can help fix the problem when the error happens.
Now the error message is:
Fetcher failure for URL: 'https://www.example.com/'. URL https://www.example.com/ doesn't work.
Please ensure your host's network is configured correctly,
or set BB_NO_NETWORK = "1" to disable network access if
all required sources are on local disk.
(From OE-Core rev: 0b31a03c59efea3a8742762772e39dcbd6f8ed25)
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>
This is helpful when debug.
(From OE-Core rev: eef945787b5717bbb5d3bbddc446d4da86e3eb62)
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 TOOLCHAINEXT_OUTPUTNAME is different from TOOLCHAIN_OUTPUTNAME, it
is used for eSDK only, so that it doesn't mix with SDK, use "?=" for it
so that other conf file can define it.
If we don't use "?=" here, then we need use forcevariable to redfine it:
TOOLCHAINEXT_OUTPUTNAME_forcevariable = "foo"
(From OE-Core rev: 933539a07af3f1cca79e49b0ea92cb7699095f96)
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>
This patch has been superseded by 2907b1 in gobject-introspection, which we're
now shipping.
(From OE-Core rev: f5c11a40008801aef5ab8df10ee837ad23c24b8d)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This makes more sense than the default TERM=linux (as set
by the linux kernel).
In addition, when using busybox init, it tries to achieve
the same (in a different way).
Both agetty, and busybox getty support the terminal type as
the last argument.
(From OE-Core rev: a23004f32dda9310c7efc29720fa9c3027a7c329)
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>
When uninstalling update-alternatives, it doesn't seem to
make much sense to keep the update-alternatives database
around.
In particular when removing packaging data, e.g. due to
read-only rootfs, update-alternatives is removed from
the target file system. Leaving its database around
serves no purpose in that case as there is no way to
use it afterwards anyway.
This frees close to 700KB of (uncompressed) space in
a busybox based environment.
(From OE-Core rev: b24a63d71b517af701dfedbc7f7b541d25af708f)
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>
If you have a file:// entry in SRC_URI with a subdir= parameter that
makes it extract into the source tree, then when you update that file in
oe-local-files and run devtool update-recipe then you want the original
file to be updated. This was made to work by OE-Core commit
9069fef5dad5a873c8a8f720f7bcbc7625556309 together with
31f1bbad248c36a8c86dde4ff57ce42efc664082, however until now there was no
oe-selftest test to verify it.
Note that in order to succeed this test also requires the fix
"lib/oe/recipeutils: ignore archives by default in
get_recipe_local_files()" since the test recipe uses a local tarball.
(From OE-Core rev: 936eba3e1059d1dcd5e58c1ce76870fff7b11b3c)
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>
By default, have get_recipe_local_files() not return any archive
files. This prevents a local tarball from being erroneously removed
from SRC_URI if you run "devtool modify" on a recipe followed by
"devtool update-recipe". It doesn't actually help you to directly
update the contents of such tarballs, but at least now it won't break
the recipe.
(From OE-Core rev: e9c418d4704c1bed4c5880e176e5288485f4f5a6)
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>
If you have a patch remotely fetched in a recipe (e.g. from an http
server) that needs updating then add a local version and substitute the
entry in SRC_URI to point to it.
One can argue about how desirable it is to be modifying patches fetched
in this way, but then one can argue about how desirable it is to have
such patches in the recipe in the first place - and in any case if
devtool update-recipe is to correctly transfer changes to such patches
made in the git repository within the source tree to the recipe then
there isn't much choice but to do it this way.
(From OE-Core rev: a19c26cc78a181f9dd2706dd42e7e450d7ad4082)
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>
It is possible to use gzip or bzip2 to compress patches and still refer
to them in compressed form in the SRC_URI value within a recipe. If you
run "devtool modify" on such a recipe, make changes to the commit for
the patch and then run devtool update-recipe, we need to correctly
associate the commit back to the compressed patch file and re-compress
the patch, neither of which we were doing previously.
Additionally, add an oe-selftest test to ensure this doesn't regress in
future.
Fixes [YOCTO #8278].
(From OE-Core rev: e47d21624dfec6f71742b837e91da553f18a28c5)
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>
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: d9971f5dc8eb7de551fd6f5e058fd24770ef5d78)
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>
Add a test to ensure devtool update-recipe works properly on recipes
that contain only local files (since the other tests we have didn't test
that).
Relates to [YOCTO #10563].
(From OE-Core rev: bdc844b3f0c3fbddcd3523095899a5bd29797704)
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>
As of the move to Python 3 and the fixes we applied at that time,
bb.process.run() will return a byte array of length 0 rather than an
empty string if the output is empty. That may be a bug that we should
fix, but for now it's easiest to just check the result here before
treating it as a string. This fixes running "devtool update-recipe" or
"devtool finish" on a recipe which has no source tree, for example
initramfs-framework.
Fixes [YOCTO #10563].
(From OE-Core rev: 66bf6978fc807ecc422fb6b6328f68bc3406cf15)
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>
We strip the TOOLCHAIN_OPTIONS and HOST_CC_ARCH from CC/CXX in cmake.bbclass
whereas CFLAFS and CXXFLAGS assume that TOOLCHAIN_OPTIONS are
part of CC/CXX variables, this causes compile failures when cmake
is running compiler tests during configure on some architectures
especially armhf, because hf ABI information -mfloat-abi is part
of TOOLCHAIN_OPTIONS, so what happens is that testcase gets compiled
without hard-float, howver, during linking the float ABI option
is passed via LDFLAGS, now linker rejects this and fails like
/mnt/a/build/tmp-glibc/sysroots/x86_64-linux/usr/libexec/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/6.2.0/ld: error: cmTC_27947 uses VFP register arguments, CMakeFiles/cmTC_27947.dir/src.cxx.o does not
mnt/a/build/tmp-glibc/sysroots/x86_64-linux/usr/libexec/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/6.2.0/ld: failed to merge target specific data of file CMakeFiles/cmTC_27947.dir/src.cxx.o
collect2: error: ld returned 1 exit status
This means that CMake now fails the configure time test too
which is not right, e.g. it might disable features which actually do exist
and should be enabled e.g. in case above it is resulting as below
Performing C++ SOURCE FILE Test HAS_BUILTIN_SYNC_SUB_AND_FETCH failed with the following output:
Its actually a bug in CMake see
https://gitlab.kitware.com/cmake/cmake/issues/16421
CMake is ignoring CMAKE_CXX_FLAGS when using CHECK_CXX_SOURCE_COMPILES
function.
Until it is fixed upstream, we add HOST_CC_ARCH and TOOLCHAIN_OPTIONS
to CFLAGS and CXXFLAGS, so that we can ensure that compiler invocation
remains consistent.
(From OE-Core rev: 826f3cdb474b5728b22f08d2342fc90235ca9e7d)
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>
The TIFFWriteDirectoryTagLongLong8Array function in tif_dirwrite.c in the tiffset tool
allows remote attackers to cause a denial of service (out-of-bounds read) via vectors
involving the ma variable.
External References:
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-3658http://bugzilla.maptools.org/show_bug.cgi?id=2546
Patch from:
45c68450be
(From OE-Core rev: c060e91d2838f976774d074ef07c9e7cf709f70a)
Signed-off-by: Zhixiong Chi <zhixiong.chi@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When a systemd service file has changed it is required to reload
systemd's configuration. Otherwise changes to a service file will not be
picked up during package upgrade.
(From OE-Core rev: 94efe6d1d7893e241bcf98eff80ac8d8fbf2e885)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Scott Rifenbark
Fabio Berton
Jussi Kukkonen
Jiajie Hu
Yi Zhao
Jose Lamego
Edwin Plauchu
Edwin Plauchu
Otavio Salvador
Khem Raj
Chen Qi
California Sullivan
T.O. Radzy Radzykewycz
Joshua Lock
Leonardo Sandoval
Paul Eggleton
Olof Johansson
Carlos Alberto Lopez Perez
Stephano Cetola
Maciej Borzecki
Max Krummenacher
Robert Yang
Ross Burton
André Draszik
Zhixiong Chi
Linus Wallgren