This class is useful on its own and can be used to create configuration
recipes.
(From OE-Core rev: 5d14ff6e25d3b334d4cc9363a6ddeb16f4c2911d)
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We can't guarantee the kernel will be named vmlinuz anymore. Use
KERNEL_IMAGETYPE instead.
(From OE-Core rev: 8e9a5350e51d4c3be5417e55e4fd1428f49f3d8b)
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We can no longer rely on the kernel having a static name of "vmlinuz".
This means we can't use it as a sentinel value in our sed commands, and
we can't just copy vmlinuz to the boot directory.
Instead, we'll use "root=" as the sentinel value for our sed commands,
and we'll search for common kernel names to copy into our boot
directory.
(From OE-Core rev: 3d67edb695368bfa5917dca2aab6a8dc4c437efc)
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using --exclude-path and a wks.in file we can create an image that takes
the /boot/ directory for the boot partition, has an empty /boot/
directory in the rootfs partition. The boot partition gets mounted to
/boot/ after startup.
(From OE-Core rev: db904053e8ee80fb6930c5e7e22287927e0f25e2)
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rather than renaming the kernel to vmlinuz and assuming the name is
vmlinuz in the grub.cfg, copy to ${KERNEL_IMAGETYPE} and also use that
value in the grub.cfg file.
(From OE-Core rev: d37be17527b354fddb3a5740d0197c590d620f42)
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I can't find VM_DEFAULT_KERNEL used anywhere else, and we should not be
statically installing the kernel as vmlinuz.
(From OE-Core rev: 5493bb5ba4b4520f944d38b214a3d53a5282e0be)
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since the bootloader is now installed instead of added at image creation
time, this is necessary for booting.
Also set the default to grub-efi. This is done because a default of
grub-efi is already used by live-vm-common.bbclass, and in the event
that EFI_PROVIDER isn't defined errors would occur.
(From OE-Core rev: d8a670726fb6b2553c792a1c66346f975f040135)
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This way we could theoretically support multiple bootloaders, and we
keep the convention of boot(x64|ia32).
(From OE-Core rev: 8d158bb4382fd4ef31d37ea5558e07d5eb33145e)
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since /boot/ will be recipe/package controlled now we can't just deploy.
(From OE-Core rev: f9c3405a99f3c0fd922d21bea7bb0bd0dd3a2ab2)
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This makes use of the grub-efi-cfg bbclass that was split out to create
a grub.cfg file just like the old one.
(From OE-Core rev: eff14ba3e49d77bfc8167a19a0f58563270f2a51)
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This part is useful on its own, whereas the whole class together is
specific for image-live.
(From OE-Core rev: 8daf2c544eb40d97d99a41627ddc5529c0e23f3c)
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For arm we enforce ARM mode regardless of ARM_INSTRUCTION_SET
choice from config metadata, glibc works fine with thumb2 for
armv7+ so limit the restriction to armv5 and lower, tested on
rpi3 works equally well as arm mode glibc and sheds about 0.5MB
in size for main package alone. Other glibc build packages also
gets smaller
ARM: 2696 KiB libc6
Thumb2: 2132 KiB libc6
(From OE-Core rev: a22b97aff811566399765d755daffddb28f82857)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Also, take over the other recipes that were just enabled for
ptest:
- liberror-perl
- liburi-perl
- libxml-parser-perl
- libxml-perl
- libxml-simple-perl
(From OE-Core rev: 7758debbf1bd814606307dd8b8200a9504bb5701)
Signed-off-by: Tim Orling <timothy.t.orling@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Enable ptest by inheriting new ptest-perl.bbclass
* Remove t/cwd.t and t/file.t which require "-T"
(taint) command line option as they will fail.
(From OE-Core rev: e88c7fc244c6abe3148f60c8988234342c351dfb)
Signed-off-by: Tim Orling <timothy.t.orling@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Skip tests when modules not available
* Dependency for ptest of liburi-perl
(From OE-Core rev: 2735e7bfe20a31497a6b975c67ac689eccd5950e)
Signed-off-by: Tim Orling <timothy.t.orling@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we're building a SDK and we're using glibc so may be installing locales,
add a build-dependency on natiesdk-glibc-locale so the locales we need will
exist.
(From OE-Core rev: 8d6869a0a89d8cf3c6e57723fab2750ba2c885db)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using glibc-locale to install locales only makes sense if we're using glibc.
(From OE-Core rev: 8fc80734053645fa893694dfe33ddaee99aa9a1a)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is basically a copy/paste of buildtools-tarball so copy some of the
recent changes to buildtools across.
(From OE-Core rev: bb10cec25e3683de4fda11e66f827c882488cb1a)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Because I didn't really want python3-native to be at the bottom of the
entire X11 stack this recipe jumps through a small hoop to use the host
Python to run some modules it installs into the sysroot.
The Makefile compiles the Python module, which is good as the cache file
is recorded in the sstate manifest so when the package is removed from the
sysroot all of it is removed.
However in an enviroment where the sstate is shared between multiple hosts
it is possible that a different Python is used and this will generate a
new cache when the code is executed, which is not recorded in the manifest.
Eventually you'll end up with ownerless cache files in a sysroot which
conflict with the same file coming from a sstate upgrade.
Solve this with a SSTATE_INST_POSTRM which is ran when sstate is removed
to ensure that there are no Python cache files left behind.
[ YOCTO #11809 ]
(From OE-Core rev: 6f6a2b5ff7ec23bd3782f0c3521f3576101cbc9d)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Similar to sysvinit-inittab
(From OE-Core rev: a673d5bbf7e4db6de9a5151df041e6c5db7e413e)
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Create busybox-inittab recipe to produce machine-specific package with /etc/inittab
and necessary getty calls for a machine, based on SERIAL_CONSOLES, similar to how
sysvinit-inittab was done
* Since CONFIG_FEATURE_USE_INITTAB is controlled by VIRTUAL-RUNTIME_init_manager, make
main busybox package RDEPENDS on busybox-inittab when init_manager is set to busybox
(From OE-Core rev: afb09abd2f0f7555ba156260a87fd3867f591310)
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The base configuration needs key expansion and anon python execution,
the parsed configurations do not. Fix this consistently, its been
broken and causing double key expansion for a while, only relised
when we started double anonymous python exeution too.
(Bitbake rev: 6138897de5ac6becf3bff56ce7a78f3ec208fcdf)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The output of bitbake -e can differ from what actually is used due
to anonymous python making changes to the data store. Execute any
anonymous python added in the base configuration to make things
more consistent.
(Bitbake rev: bcdc2f73e3b4a10b1e479c2891f251d9507a9e30)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows us to call this code from other contexts without
duplicating it.
(Bitbake rev: c6be487f9bd5d95915f2495d555b9f539adb1d44)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Handling of backfilling is trickier than you'd think. We need this to execute
early enough that the user will see the changes in bitbake -e and other output
yet late enough that the virtclass extensions have changed the tunes before
it executes.
It makes more sense to execute this at anonymous python time now bitbake -e
correctly handles this and that unbreaks multilib corruption of these variables.
[YOCTO #12373]
(From OE-Core rev: cefd312541019c1bb0132f41334df58971fd81ef)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now we're filtering tasks in the rpm indexing code so that tasks can only
see the packages they really depend upon, having noexec package_write tasks
around is causing problems since the tasks exist but don't have manifests.
Removing the tasks entirely solves this problem and streamlines the
task execution graph too.
(From OE-Core rev: 027445cd88a4e706bdfe83bb4ff2c21e2186982a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now bitbake is executing anonymous python fragments in bitbake -e,
ensure we don't show the error in that context (where PN would be
unchanged from default).
(From OE-Core rev: 79240b3af32c7fa44751752e9e8f2ff832439643)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add runtime test for opkg to test that it can install ipk
package from remote source.
[YOCTO# 11488]
(From OE-Core rev: 9dd4af2b70f58540b2799823957aff3413068126)
Signed-off-by: Yeoh Ee Peng <ee.peng.yeoh@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add runtime test for apt to test that it can install deb
package from remote source.
[YOCTO# 11488]
(From OE-Core rev: f380fa77d69051212fdf7dff97da611e884d05d2)
Signed-off-by: Yeoh Ee Peng <ee.peng.yeoh@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Build date ends up embbedded in binary images, breaking reproducibility
of jpeg-tools and libturbojpeg. To enable reproducible builds, build date can be
specified during configuration, via "--with_build_date=<date>".
If SOURCE_DATE_EPOCH is specified we configure libjpeg-turbo with this value as
build date. Although the build date is a generic string, we keep it in the same
format YYYYMMDD.
[YOCTO #12526]
(From OE-Core rev: 46a39fe9fa2bc8f58ec822434b9ace9ab5572c82)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
dlvsym() is used by the libepoxy test suite, but this is glibc-specific and
isn't present in musl.
Instead of adding an option to control whether dlvsym is available (which could
be detected by Meson), as we don't install the test suite simply add an option
to disable the entire test suite (and submit the patch upstream).
Also remove the build dependency on util-macros as that is a remnant of the
autotools build.
(From OE-Core rev: 80cee6088fa60eb5197f8ed9d135986b8e7d471a)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
