linux/poky.git/meta/classes/sanity.bbclass, branch 3.2_M2

sanity.bbclass: Detect and fail if 'inherit' is used in conf file

2020-05-24T22:56:03+00:00

'inherit' directive may not be used in conf files as it's supposed to be used for the inheritance of classes. Correct form in conf file is INHERIT. This commit adds: - a sanity check to find whether the wrong case exists - fail the build if so - tell user about the difference in directives [YOCTO #5426] (From OE-Core rev: 07bf9b460fe97dec86439302a83bbefa8bac9d70) Signed-off-by: Gregor Zatko Signed-off-by: Richard Purdie

sanity: Require gcc 6 or later

2020-05-02T08:08:52+00:00

New versions of rpm have issues with the libgomp support in gcc 5.x so raise the minimum to 6 or later. This mainly affects Ubuntu 16.04. (From OE-Core rev: aca2e5816203b54e0955eaa99fc980d010052d5d) Signed-off-by: Richard Purdie

Windows: Enable Windows builds under WSLv2 and warn accordingly

2020-04-06T13:25:52+00:00

Due to the architectural changes between Windows Subsystem for Linux v2, and WSL v1 it should now be possible to run bitbake on the several distros offered through the Microsoft Store. WSLv2 is available on Windows 10 build number > 18917 The current build number may be checked by opening a cmd prompt on Windows and running: C:\Users\myuser>ver Microsoft Windows [Version 10.0.19041.113] If a distro has already been installed via the Microsoft Store, then we can check which WSL version its using by opening a Windows Powershell (notice this is a powershell and not a cmd prompt): C:\WINDOWS\system32> wsl -l -v NAME STATE VERSION * Ubuntu Running 2 Debian Stopped 1 In this case it shows two distros installed, Ubuntu running WSLv2 and Debian running WSLv1 To change the version of WSL being used by a certain distro run: C:\WINDOWS\system32> wsl --set-version 2 e.g C:\WINDOWS\system32> wsl --set-version Debian 2 For more information on installing WSLv2 please look at: https://docs.microsoft.com/en-us/windows/wsl/wsl2-install There are some caveats related to the way storage is handled by WSLv2 though, and at this point these have to be managed by the user manually, the storage space used by WSL is not reflected immediately and since bitbake heavily uses storage, after several builds this can prove to be a bit of an issue. WSLv2 uses a VHDX file for storage, this issue can be easily avoided by optimizing this file every now and then, this can be done via the following: 1.- Find the location of your VHDX file: - Get the distro app package directory. - Open Windows Powershell as Administrator and run: Get-AppxPackage -Name "**" | Select PackageFamilyName e.g.: PS C:\WINDOWS\system32> Get-AppxPackage -Name "*Ubuntu*" | Select PackageFamilyName PackageFamilyName ----------------- CanonicalGroupLimited.UbuntuonWindows_79abcdefgh Replace the PackageFamilyName (and your user) on the following path: C:\Users\\AppData\Local\Packages\\LocalState\ e.g. ls C:\Users\\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState\ Mode LastWriteTime Length Name -a---- 3/14/2020 9:52 PM 57418973184 ext4.vhdx The VHDX file path is: C:\Users\\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState\ext4.vhdx 2.- Optimize your VHDX file (Also on Powershell): - Make sure WSL is shutdown wsl --shutdown - Optimize it optimize-vhd -Path C:\Users\\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState\ext4.vhdx -Mode full A progress bar should be shown while optimizing the VHDX file. As an example, after building core-image-sato, removing the TMPDIR did not reflect any changes on Windows Explorer for storage space being used, after optimizing the VHDX file, 14 extra GB were shown as free. So, as long as the the user optimizes its storage, the builds should run smoothly. This patch warns the user that is running bitbake under WSLv2, that they should optimize the VHDX file eventually to avoid storage issues. The same check previoulsy used for WSLv1 works for WSLv2, checking for the kernel version: WSLv1: Linux version 4.4.0-19041-Microsoft (Microsoft@Microsoft.com) WSLv2: Linux version 4.19.84-microsoft-standard (oe-user@oe-host) Builds have been tested under Ubuntu and Debian distros offered and installed through the Microsoft Store, and other distros should be able to run builds just as fine. Performance wise, using the same hardware, and same configuration a comparison between builds using native Linux vs WSLv2 for the following targets has been performed: - core-image-minimal - core-image-sato - core-image-sato-sdk - meta-toolchain No real evidence of any performance changes could be found, with WSLv2 builds running even faster in some cases. Running a recently built image can be done just as smoothly, if using "nographic" as argument for runqemu, or if its a graphical image, installing an X server and running runqemu runs just as fine. Happy bitbaking. (From OE-Core rev: c42cec0c1c57c4e67dc7cdb07c5e4aba14a847d3) Signed-off-by: Alejandro Hernandez Samaniego Signed-off-by: Alejandro Hernandez Samaniego Signed-off-by: Richard Purdie

sanity.bbclass: echo current SDK_VENDOR if it is invalid

2020-04-05T10:46:38+00:00

It can be frustrating if this sanity check triggers, but you don't know why; you haven't explicitly set any SDK vars, or similar. At least echo out the offending value, so the end user has a bit more information to go on. Before: SDK_VENDOR should be of the form '-foosdk' with a single dash After: SDK_VENDOR should be of the form '-foosdk' with a single dash; found '-overc-sdk' Cc: Ross Burton (From OE-Core rev: e238fa177bd72bc5d165fbe4f640132267a1d3fd) Signed-off-by: Paul Gortmaker Signed-off-by: Richard Purdie

sanity: Require gcc 5.0 minimum version

2020-04-05T10:46:37+00:00

After polling various develoeprs, its clear that many layers are struggling with gcc 4.8 and its better for the project to adopt 5.0 as a minimum version at this point in time. We should have technology like buildtools-extended-tarball available to ensure things still work on Centos 7 and Debian 8. (From OE-Core rev: abc741af16311cb473b7e3185ae34265b243d804) Signed-off-by: Richard Purdie

sanity.bbclass: add test for gcc < 4.8

2020-04-01T10:44:24+00:00

It is known that old versions of gcc prior to 4.8 causes builds to fail. Add a test for BUILD_CC == 'gcc' and gcc < 4.8 and recommend using scripts/install-buildtools or user built buildtools-extended-tarball. Use the new get_host_compiler_version function from lib/oe/utils.py NOTE: another solution is to install devtoolset-6+ from scl [1], but this is a rather large install (> 1 Gb) and fairly invasive. [1] https://www.softwarecollections.org/en/scls/rhscl/devtoolset-6/ Adding this code means we can increase the minimum version easily in the future too (which will soon be needed). RP: Change minimum version from 5.0 to 4.8 for initial patch (From OE-Core rev: 3bb3b9cbad82b2f09386153226d1d4e769b7347b) Signed-off-by: Tim Orling Signed-off-by: Richard Purdie

sanity.bbclass: recommend using install-buildtools

2020-04-01T10:44:23+00:00

For old tar version (< 1.28), recommend using scripts/install-buildtools Drop check for tar version 1.24. Dubious extra value. (From OE-Core rev: 7a66434cf11b7f051699b774e4fccd6738351368) Signed-off-by: Tim Orling Signed-off-by: Richard Purdie

bitbake.conf/sanity: Drop makeinfo as being required on buildhost

2020-02-03T00:10:11+00:00

This is a long standing 'odd' dependency which we've meant to resolve. We shouldn't need it and it introduces reproducability issues. We already have texinfo-dummy-native and texinfo-native which can provide it but the work to remove the hosttool was never completed. After cleaning up texinfo.bbclass, this can now be removed with minimal impact on build time. [YOCTO #13753] (From OE-Core rev: 0c58c479af151969dfb84d8763696da657f7248d) Signed-off-by: Richard Purdie

sanity.bbclass: Move sanity_info from conf to cache

2020-01-10T21:18:22+00:00

Since this file is written during recipe parsing, having it in the ${BUILDDIR}/conf directory, which is covered by an inotify watcher, will trigger a re-parse the next time bitbake is run and the resident bitbake server is enabled. This causes the sanity_info file to be updated again, which triggers a new parse the next time bitbake is run ad infinitum. Moving it to ${BUILDDIR}/cache should avoid this. (From OE-Core rev: f98103b548aa7dba6b1be6c8e02ef41858a8e85c) Signed-off-by: Peter Kjellerstedt Signed-off-by: Richard Purdie

sanity: Add check for tar older than 1.28

2019-11-22T23:13:06+00:00

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: 0fdc43da005c3c6102cf07383ad6f451d2203fa5) Signed-off-by: Richard Purdie