Drop upstreamed gi-flags.patch and gtkdoc-flags.patch, rebase the rest.
(From OE-Core rev: 6cc5c57c38d2da37b4f15dea6e1fb97e3a0bae73)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The libnolto_coregrind_a_OBJECTS is in libcoregrind_a_LIBADD, so the objects
should be ready before generate libcoregrind.a, otherwise there would be
failures:
i586-poky-linux-ar: libnolto_coregrind_x86_linux_a-m_libcsetjmp.o: No such file or directory
make[3]: *** [libcoregrind-x86-linux.a] Error 1
Add libnolto_coregrind_a_OBJECTS to EXTRA_libcoregrind_DEPENDENCIES to fix the
problem.
This is a race issue during parallel build.
(From OE-Core rev: 713d6978894269e5b463c3731c03da7e83956743)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The line was added in
os-release: add the public package-signing key
f7359ad6bec82d4aa761287a6c6d53cbc25adab3
but the actual usage was removed in
signing-keys: Make signing keys the only publisher of keys
1e38068ac38dfd067655dfd41464e28439179306
(From OE-Core rev: 05aeb9de239beff4bfdb3cd7dc39d484ecb69190)
Signed-off-by: Jacob Kroon <jacob.kroon@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* in some rare cases the file format might be broken, e.g. when you run
out of disk space while writing to it (hint: make sure to use
BB_DISKMON_DIRS on _all_ the builds, to make sure that they can stop
gracefully before this happens).
* will show error like this:
ERROR: Invalid line '/OE/build/luneos-thud/webos-ports' in sstate manifest '/OE/build/luneos-thud/webos-ports/tmp-glibc/sstate-control/index-allarch'
when the file isn't complete, like in my case:
$ tail -n 2 /OE/build/luneos-thud/webos-ports/tmp-glibc/sstate-control/index-allarch
/OE/build/luneos-thud/webos-ports/tmp-glibc/stamps/all-webos-linux/org.webosports.app.calculator/0.1.1+gitrAUTOINC+9e9eb67c28-r0 /OE/build/luneos-thud/webos-ports/tmp-glibc/sstate-control/manifest-allarch-org.webosports.app.calculator /OE/build/luneos-thud/webos-ports/tmp-glibc/work/all-webos-linux/org.webosports.app.calculator/0.1.1+gitrAUTOINC+9e9eb67c28-r0
/OE/build/luneos-thud/webos-ports
* instead of much longer exception which doesn't really show what's
wrong to selectively fix that (other than removing while TMPDIR):
ERROR: Command execution failed: Traceback (most recent call last):
File "/OE/build/luneos-thud/webos-ports/bitbake/lib/bb/command.py", line 113, in runAsyncCommand
self.cooker.updateCache()
File "/OE/build/luneos-thud/webos-ports/bitbake/lib/bb/cooker.py", line 1562, in updateCache
bb.event.fire(event, self.databuilder.mcdata[mc])
File "/OE/build/luneos-thud/webos-ports/bitbake/lib/bb/event.py", line 225, in fire
fire_class_handlers(event, d)
File "/OE/build/luneos-thud/webos-ports/bitbake/lib/bb/event.py", line 134, in fire_class_handlers
execute_handler(name, handler, event, d)
File "/OE/build/luneos-thud/webos-ports/bitbake/lib/bb/event.py", line 106, in execute_handler
ret = handler(event)
File "/OE/build/luneos-thud/webos-ports/openembedded-core/meta/classes/sstate.bbclass", line 1083, in sstate_eventhandler2
(stamp, manifest, workdir) = l.split()
ValueError: not enough values to unpack (expected 3, got 1)
(From OE-Core rev: 870ba5d80e76e0f989971532fc2adc0ebe811ab6)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Before linux commit d36b691077dc59c74efec0d54ed21b86f7a2a21a, some
strings contained invalid utf-8 character which made
split_kernel_module_packages unhappy when parsing ums-isd200.ko:
Exception: UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf6 in position 21: invalid start byte
(From OE-Core rev: 503b977acf6984120818cbc5cfd35ff2cffb39cd)
Signed-off-by: Pau Espin Pedrol <pespin@sysmocom.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In OE we do not build mutlib like gcc does it by default, this ensures
that mutlilib is virtually disabled for OE, since we hardly use same gcc
to build for multiple ABIs
This fixes cases in SDK where g++ is not able to find standard c++
include headers
(From OE-Core rev: badbeb01dd642d9d647d3760a3ce2aa39c3567da)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When pam PACKAGECONFIG is enabled a cups "pam.d" configuration file is
installed. The default configuration file uses a non-existing "pam_unknown.so",
but a different existing module can be selected by passing the
--with-pam-module parameter. Use the unix pam module when pam is enabled.
(From OE-Core rev: a7fb921e16e2eb4fa5a799b556d23d79801720b0)
Signed-off-by: Diego Rondini <diego.rondini@kynetics.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Boot parameter systemd.log_target=console affects command journalctl's
output and causes oe selftest case test_systemd_boot_time fail to pass.
| Error at obtaining the boot time from journalctl
| RESULTS:
| RESULTS - systemd.SystemdJournalTests.test_systemd_boot_time - Testcase -1: SKIPPED (0.74s)
systemd.log_target=console was introduced by oe-core commit a0bb649 and
work with parameter systemd.log_level to enable systemd debug.
systemd.log_level has been removed already, so remove systemd.log_target
too to make case test_systemd_boot_time pass.
(From OE-Core rev: caa776bdcf8ea34c857f45970370bf771075f4bc)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Append minor version to PV so recipe checker is happy
* Drop upstreamed patches
* Remove changelog from CVE patches, they dont apply and are in patch
log anyway
(From OE-Core rev: 550085bc092d773c8c481e238d0d3210466166dc)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Licence-Update: Copyright Alexander Peslyak; 0-clause BSD added
see e07290ec7c
Rename recipe to ve versionless and add PV in recipe itself, makes it
easy to traverse git history
Drop upstreamed patch
(From OE-Core rev: 2eae2d53df739acc2f89599a9296ccacbafebb60)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These warnings are intricate and we can ignore that for now as they are
being found by gcc 9, eventually this should be not needed when code
upstream is fixed
(From OE-Core rev: 42176d26e5c893e86ab5d8a2e5b8a3d021e03a69)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backport a patch that helps with this error which is found
by gcc9
(From OE-Core rev: 93419fb569b827056a422614d3dc29cd41b2b6bb)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Before, threading was enabled via a patch to opkg-build. Now that
opkg-build provides a hook for extra arguments, use that.
(From OE-Core rev: b288f4e825a036b9cc15b27301d264fe695dba65)
Signed-off-by: Alejandro del Castillo <alejandro.delcastillo@ni.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This lets linker to use its internal linker script for shared objects
Fixes with when gold is default linker
(From OE-Core rev: 7bbc453ac2b8d63680855789948a145fc448017f)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Its not needed anymore and it can depend on gcc-cross instead
(From OE-Core rev: 9dc6fcd492d41d6a65a8f5ab562830ba9372937a)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We no longer have special "libc" for gcc so we can rely on plain
virtual/libc and reduce the complexity in the dependencies.
(From OE-Core rev: 122217b421f749b5fef52bea44ad6e04bc8f8d3a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Separated out from the previous commit for clarity, this simply drops
all the -inital pieces of gcc which are no longer needed after the
previous commit.
(From OE-Core rev: d84971928b68efddbdb6344b1021d998c9e26adb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need a libgcc to build glibc. Tranditionally we therefore build
a non-threaded and non-shared compiler (gcc-cross-initial), then use
that to build libgcc-initial which is used to build glibc which we can
then build gcc-cross and libgcc against.
Firstly, we can drop the glibc dependency from gcc-cross, *if* we make
two changes:
a) specify the minimum glibc version to support in a configure option
b) create a dummy limits.h file so that later when glibc creates one,
the headers structure has support for it. We can do this with a simple
empty file
Once gcc-cross is libc independent, we can use it to build both
libgcc-initial and then later libgcc.
libgcc-initial is tricky as we need to imitate the non-threaded and
non-shared case. We can do that by hacking the threading mode back to
"single" even if gcc reports "posix" and disable libc presence for the
libgcc-intial build. We have to create the dummy limits.h to avoid
compiler errors from a missing header.
glibc will fail to link with libgcc-initial due to a missing "exception
handler" capable libgcc (libgcc_eh.a). Since we know glibc doesn't need
any exception handler, we can safely symlink to libgcc.a.
With those changes, gcc-cross can be used in all places and we only need
one build of gcc for each architecture.
For some reason ifunc was being disabled on mips prior to these changes
but afterwards became enabled but caused assertion failures. This is
therefore disabled until we can debug that.
(From OE-Core rev: 62b7308b8c4d2b439a15a4f7cbc6f823077bb0be)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The only reason we appear to need glibc-initial at this time is to support
the site_config code. The site_config code compiles and therefore needs
at least some level of working C library to link against.
This isn't a good reason to keep the complexity of glibc-initial around
so remove it, and the site_config support which then breaks.
Performance benchmarks suggest the time spent just rerunning configure
for site_config just about equals any performance benefit for OE-Core
image builds excluding the time spent adding glibc-initial to the
dependency chain.
I'm not opposed to readding some other form of site_config support
but it needs to be rethought.
(From OE-Core rev: c5df105e7583e43da9b682f739bebaf873dcd2f4)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The previous code assumed builddir and meta-selftest are in the same dir, but
this isn't always true, builddir can be anywhere, use get_test_layer() to
locate meta-selftest can fix the problem.
(From OE-Core rev: 56d2493a9adfcc47ae7e265439e05ff42cdbbbbf)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some distros use site.conf to emit certain variables which are important
for eSDK e.g. DISTRO with out which eSDK will not be able to ger right
metadata when it tries to build
(From OE-Core rev: 95659bed3f6f3216b346f70cfc9ffae9788c0fc1)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The new libpng license comprises the terms and conditions from the zlib
license, and the disclaimer from the Boost license. The legacy libpng
license license, used until libpng-1.6.35, is appended to the
new license, following the precedent established in the Python Software
Foundation License version 2.
See for details:
https://sourceforge.net/projects/libpng/files/libpng16/1.6.36/
(From OE-Core rev: 673c2dcf1045f7264570f81e2880d7a03befd2af)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For changes, see:
https://sourceforge.net/p/libpng/code/ci/libpng16/tree/CHANGES
License-Update: Added authors to license, formatting, version changes,
export classification clarification and a new libpng2 license with
clarification:
The new libpng license comprises the terms and conditions from the zlib
license, and the disclaimer from the Boost license. The legacy libpng
license license, used until libpng-1.6.35, is appended to the
new license, following the precedent established in the Python Software
Foundation License version 2.
(From OE-Core rev: 099aecfaa3baf6b24c2b751da92d7d2fa0266bf9)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changes from release notes:
- Set default background image for screen lock to an existing one
- Translation updates
(From OE-Core rev: 6a10ff0bcd6e00660a419ca535239af55e30d5aa)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Although we could potentially build patchelf and all its dependencies,
they would all have to be blacklisted to avoid trying to build them with
icecc. We use the host patchelf instead.
(From OE-Core rev: 0860216a81092fba084d29696db6d0c65a226c85)
Signed-off-by: Douglas Royds <douglas.royds@taitradio.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The python function icecc_path() was being invoked inline by set_icecc_env(),
meaning that it was being invoked at recipe-parsing time.
As a side-effect, icecc_path() was creating the recipe-sysroot directory and
symlinking icecc into it. Because this was done at parsing time (rather than
configure time), we were generating otherwise-empty WORKDIRs for *all* parsed
recipes, and for all virtual classes (-native, -nativesdk).
In my build, this generated more than 800 of these otherwise-empty WORKDIRs.
I have simplified icecc_path() to return only the intended path to the icecc
symlinks in the recipe-sysroot, with no side-effect.
We then create the directory and the icecc symlinks at configure time.
Because get_cross_kernel_cc() is still invoked at parse-time,
it needs a guard-clause for the non-kernel case.
We are now finding the host icecc at do_configure time,
so icecc needs to be in the HOSTTOOLS. I have made this non-fatal,
so that we can still inherit icecc without icecc installed.
(From OE-Core rev: d2fcaeb153fdc3f8d7143ea823139f1537055ff1)
Signed-off-by: Douglas Royds <douglas.royds@taitradio.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If two bitbake processes try to generate the ICECC_VERSION tarball at the same
time, the thread that fails to get the lock will wait 30 sec for the first to
finish. A syntax error meant that this was not happening, and in particular, if
tarball generation failed (eg. for lack of patchelf), it did so silently.
(From OE-Core rev: 4455c46bf7f49c2b44f250aa89b63b342368e2e3)
Signed-off-by: Douglas Royds <douglas.royds@taitradio.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
