summaryrefslogtreecommitdiffstats
path: root/scripts
AgeCommit message (Collapse)Author
2018-07-30wic/engine: use up all free space when expanding partitionsAnuj Mittal
Currently we just divide up the free space by the number of partitions that need to be re-sized. This leads to problems when a user has explicitly specified a subset of partitions (but not all) that need to re-sized along with the sizes. As an example, for an image with 3 partitions, if we use: wic write image.wic /dev/sdb --expand 1:10G This would lead to paritions 2 and 3 each being re-sized to one thirds of the free space instead of half. Change the behavior to use up all the free space. (From OE-Core rev: a88f1b5d88dbc5fb28be24b9787d73b9e0cdf183) (From OE-Core rev: 167d0c4a9f45e3b8172fc34bf80f3fa587513b0a) Signed-off-by: Anuj Mittal <anuj.mittal@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-07-30wic/engine: fix errors when expanding partitionsAnuj Mittal
The UEFI spec implies that GPT partitions should be assumed to be on a 2048 sector boundary (for a 512 byte sector) and the current logic just divides the free sectors available by the number of partitions that need re-sizing, which may or may not align and the final result might overshoot the limits imposed after alignment. Since we are expanding already aligned partitions, just divide up the free space in multiples of 2048. Also use the exec_cmd wrapper instead of the subprocess call directly. Fixes [YOCTO #12840] (From OE-Core rev: 5eef63f5afdfbab8e30748cb1bf42bf2e6524759) (From OE-Core rev: 2217c4ec7682adce1fe683233d80c6d54888300b) Signed-off-by: Anuj Mittal <anuj.mittal@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-07-02send-error-report: decode response from serverRobert Yang
Fixed: b'Your entry can be found here: http://<snip>' Now looks like: Your entry can be found here: http://<snip> (From OE-Core rev: 4510973fe12a61c21e12b46b8315c56f91eff5b7) (From OE-Core rev: 8a5ee520cee8c2fd0c2d87f2bba5a6a7a4729bd6) 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> (cherry picked from commit e4bacbf94a68a5ca8729b7cb2de90382c084fe7f) Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-07-02wic/bootimg-efi.py: recognize initrd when using grubAnuj Mittal
Make sure that we're able to use the initrd value specified in the wks file when using grub-efi bootloader with bootimg-efi wic plugin. Fixes [YOCTO #12689] (From OE-Core rev: f1d5bb1f21e11714357aff4ae7e52421e3756c5a) (From OE-Core rev: 941bf7bc40e11cbe9e68ccf14155196713709558) Signed-off-by: Anuj Mittal <anuj.mittal@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-07-02wic/engine.py: improve error message when required tools are missingAnuj Mittal
Instead of showing that command 'None' was found, show the name of actual command that wasn't found on the host machine or at the native sysroot path provided by user. (From OE-Core rev: 3157ebb131e01e74689b1f87a35278350f315e7d) (From OE-Core rev: 73697d9e44e92b8e7c0cdd46339981f5633f09af) Signed-off-by: Anuj Mittal <anuj.mittal@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-07-02qemux86-directdisk.wks: remove uvesafb.mode_optionAnuj Mittal
Let this be dictated by the module parameter value being set by qemu machine configuration. (From OE-Core rev: c40b241e8d40c8bc1c9e6065b12e260662f5bba4) (From OE-Core rev: 5a3dec9fb42838ddfec7c0b216367bf4c9a32db6) Signed-off-by: Anuj Mittal <anuj.mittal@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-07-02runqemu-extract-sdk: allow install debugfs on rootfsRobert Yang
Usually, the debugfs' (-dbg.tar.*) work follow is: 1) Install regular rootfs to dir_foo 2) Install debugfs (-dbg.tar.*) to the same dir_foo So we need to allow installing the debugfs on top of the rootfs. (From OE-Core rev: c54147b286d72d7c4f8ca55a5a62f5d27bd5364a) (From OE-Core rev: fdd2fca2257172251ffb0fbc6dcd60bed01ee0f0) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-06-15recipetool: fixed uncaught NameError exceptionSarah Marsh
When packaging a node application, a `NameError` can be thrown in create_npm.py if an optional npm dependency does not support Linux. (From OE-Core rev: 8293201d98d368d6322eaa960fb3e7cee2ba9368) (From OE-Core rev: c5d0afb8d7faa2c2662264e913dc2733503ec204) Signed-off-by: Sarah Marsh <sarah.marsh@arm.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-04-20wic/imager/direct: Ensure correct ROOTFS_DIR is shownRichard Purdie
This changes the output of "wic create mkefidisk -e core-image-sato" from: The following build artifacts were used to create the image(s): ROOTFS_DIR: /media/build1/poky/build/tmp.wic.ybraavmb/rootfs_copy to: The following build artifacts were used to create the image(s): ROOTFS_DIR: /media/build1/poky/build/tmp/work/qemux86_64-poky-linux/core-image-sato/1.0-r0/rootfs which s much less confusing for the user. [YOCTO #12564] (From OE-Core rev: a4941af2d3624aecc5dcd7ff54b7ea8c9e9dee8b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-04-13scripts/test-dependencies.sh: removeMartin Jansa
* with RSS used in pyro this script isn't very useful anymore * RSS makes sure that the dependencies are almost always deterministic the only case known to me where dependencies are different based on what was already built in TMPDIR are runtime dependencies resolved by shlibs code in package.bbclass (which is using global pkgdata, not specific to given recipe and its RSS) as described here: https://bugzilla.yoctoproject.org/show_bug.cgi?id=9217#c4 but for this case it's not worth running complete test-dependencies.sh runs (From OE-Core rev: ac582a8f856de8dde6a04d9c1da58618b80559b6) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-04-10yocto-check-layer: add a test for correct setting of ↵Alexander Kanavin
LAYERSERIES_COMPAT_collection [YOCTO #12661] (From OE-Core rev: 13a80b22f28b81a0082d181674295a0f96111f6b) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-04-07devtool/oeqa: Ensure added layers set LAYERSERIES_COMPATRichard Purdie
Now that we see warnings if LAYERSERIES_COMPAT is unset, the auto generated code from devtool/oeqa needs to set this to avoid warnings which break various tests. (From OE-Core rev: 27568410ebb0d40db3428550704f35199df0e034) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-04-07crosstap: replace script with new python based implementationVictor Kamensky
New crosstap python implementation is total replacement for crosstap shell script, that has superseding capabilities. New script support cross compiling of SystemTap scripts for user-land, by using supplied image rootfs. Whereas old script could only deal with scripts against kernel. New script has more complex logic and additional capabilities. As invocation interface new script support old "legacy" mode and provides alternative new regular options interface to access additional functionality. (From OE-Core rev: 1cbbcf26e0a9ca6e0b34a89512bf75dbae8bfaf0) Signed-off-by: Victor Kamensky <kamensky@cisco.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-04-03recipetool: create: fix port number parsing issueMing Liu
A flaw was found when I run: $ recipetool create "ssh://git@xxx.xxx:7999/xxx.git" the url turned out to be: "git://git@xxx.xxx/7999/xxx.git;protocol=ssh" after parsing, the port number was parsed as part of the path, this is definitely wrong and lead to fetching failures. This issue could be fixed in reformat_git_uri, by filtering out port numbers when formatting ":". (From OE-Core rev: 4290e04b69360b5e1da9f37166015e30f66cb335) Signed-off-by: Ming Liu <liu.ming50@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-03-30scripts/oe-setup-rpmrepo: remove the scriptYi Zhao
After we switched to RSS, this script was not working for a long time. 'bitbake package-index' can do the same thing and works well. So remove this script. (From OE-Core rev: 94fea92f5e7f7c0765e89743a1586b22186a16cd) Signed-off-by: Yi Zhao <yi.zhao@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-03-20checklayer: remove reference to undefined classAnuj Mittal
LayerError doesn't exist and will lead to an error when this failure code path is hit. (From OE-Core rev: 7780482772d005c77825dc3e99e63f00911156bf) Signed-off-by: Anuj Mittal <anuj.mittal@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-03-16scripts/oe-build-perf-report: fix comparing arbitrary commitsMarkus Lehtonen
Fix a crash when generating a txt report and the two commits to be compared were not consecutive (but there were some tested commits between them). (From OE-Core rev: f3afd2c47f4c740df52dfd80e208ce721d5ebf6e) Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-03-15build-recipe-list: improvementsRoss Burton
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-03-15build-recipe-list: build universe instead of worldRoss Burton
Building world means recipes that are excluded from world build for whatever reason get skipped from the manifests, which isn't useful. Instead building universe and pass -k so that the expected dependency failures are not fatal. (From OE-Core rev: 2d798f9f56fbd7cd20de4b797a476ad24c214ff3) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-03-11devtool: add --force-patch-refresh to 'modify' and 'finish' commandsAlexander Kanavin
This is very useful for updating patch context so that any fuzz is eliminated. Simply issue: devtool modify <recipe> devtool finish --force-patch-refresh <recipe> <layer_path> Without this flag, devtool will not deem the commits in the workspace different to patches in the layer, even if the commits have different, up-to-date context line in them. (From OE-Core rev: 7e1d1887be8faaaab9996fca9a3fd750aeb7b62f) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-03-06wic: add wks file to make use of exclude-path functionalityCalifornia Sullivan
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>
2018-03-04wic: Set a miniumum FAT16 volume size.Paulo Neves
Set a miniumum FAT16 volume size because images are not valid to parted if this minimum value is not respected. The value set is determined experimentally forr a logical sector size of 512. This fixed my local problem but, there may be better solutions. (From OE-Core rev: f7dfb4d43247d3c13a4e0a3853007d63b9512b83) Signed-off-by: Paulo Neves <ptsneves@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-03-04wic: partition plugin wrongly assumes it is rootfsPaulo Neves
The partition plugin is used as the base for other plugins. One of the methods the plugins use, is the prepare_rootfs method. The prepare_rootfs method wrongly assumes that the value ROOTFS_SIZE from bitbake datastore is relevant to every invocation of prepare_rootfs, which it clearly is not, for example in the bootimg-partition case. This commit adds an optional argument to prepare_rootfs where a caller can tell prepare_rootfs if it is an actual rootfs and whether related rootfs information retrieved from bitbake is valid. The default behavior of this optional argument is to assume that the invocation is an actual rootfs, to maintain compatibility with previous implementations. (From OE-Core rev: 654d72d55194ec41bc1aacfcc6b2c8c9a305b042) Signed-off-by: Paulo Neves <ptsneves@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-03-04wic: Add post operation hook for SourcePluginParthiban Nallathambi
do_post_partition hook is needed if some operations like security signing the parition needs to be done. source plugins can make use of this to implement post operatiosn in do_post_partition. do_post_partition is called after do_prepare_partition if present. (From OE-Core rev: 5055489b9ab3fda32a285d0d165d080d11a4d432) Signed-off-by: Parthiban Nallathambi <pn@denx.de> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-03-01devtool: search: tweak help textPaul Eggleton
* We now match on more than just target recipes, so don't specify that only target recipes are searched. * We're printing the SUMMARY value in addition to the name, so mention that so it's clear where that text is coming from. * Remind users that they should use quotes around the keyword to avoid shell expansion when using regular expressions. (From OE-Core rev: cc68971557fe065e59ff47657f650051eb85db3c) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-03-01devtool: search: also look in recipe cachePaul Eggleton
If pkgdata isn't present or is incomplete, then you get either a traceback or you don't see the results you were hoping for. The recipe cache that bitbake collects during startup contains some useful information for each recipe that we could search through as well, and we can access it easily using tinfoil's all_recipes() API function, so add some code that does that. (We still show a warning if pkgdata isn't present, as there are certain dynamic packages that are generated at packaging time that won't show up in the cache). One side-effect of this is that we will start showing non-target recipes - that's actually a good thing, since seeing those is useful, however we exclude nativesdk recipes when in the eSDK to avoid confusion since nativesdk isn't directly applicable there. Fixes [YOCTO #12356]. (From OE-Core rev: b8406383886d09a80a9a002150dcf364fa9902d7) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-03-01devtool: deploy-target: don't specify ssh/scp port unless user doesPaul Eggleton
If the user doesn't specify a port then we should avoid specifying one on the ssh/scp command line in case the user has configured one for the host they are connecting to, which was being overridden unnecessarily. Fixes [YOCTO #12381]. (From OE-Core rev: f1020eef09fada7ef2231d5528576553f3f6bfe1) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-03-01devtool: finish: fix erroneously creating bbappend for relative pathsPaul Eggleton
After OE-Core rev 5e3fe00a0233d563781849a44f53885b4e924a9c we call os.path.abspath() on the original layer path, but we later compare that to the destination layer path. If that layer path isn't absolute but is effectively the same path, it should be writing to the original recipe but because we weren't making it absolute we were writing a bbappend instead. Call os.path.abspath() on the destination path as well to avoid that. (From OE-Core rev: a85a78dcf226d160e9b504bfa67b306a9175ac29) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-03-01devtool: reset: delete bbappend file if _check_preserve() doesn'tPaul Eggleton
If the .devtool_md5 file doesn't contain a reference to the bbappend file (e.g. because devtool was interrupted before it could write that out) then _check_preserve() won't delete it, so we need to delete it separately because otherwise the recipe won't actually be reset. (From OE-Core rev: 751d27600a3df18d96baaa48696acf33ee964bec) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-03-01devtool: fix poor handling of upgraded BBCLASSEXTENDed recipesPaul Eggleton
Fix two aspects of handling BBCLASSEXTENDed targets (e.g. openssl-native) that have been run through "devtool upgrade": * Fix recipe name not showing up in "devtool status" * Fix "devtool reset" not deleting empty directories under the recipe directory within the workspace, which may lead to problems if you subsequently run "devtool upgrade" on the same target again (From OE-Core rev: 56e04260d64de9c5b83893d97cf41b7ea9a45878) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-03-01oe-init-env: search 'bitbake' outside of oe-coreEnrico Scholz
atm, 'oe-init-build-env' expects 'bitbake' to be within the OE core git repository. This complicates the project setup because you have to manage the 'bitbake' directory or symlink manually (or specify the bitbake location explicitly). Looking for 'bitbake' outside the main git repository will ease project management significantly. Now, you can put everything into git submodules, clone the project with | git clone --recursive ... and continue immediately with | ..../oe-init-build-env E.g. when you had previously | . | |-- build/ | `-- sources/ | `-- org.openembedded.core/ | `-- bitbake -> ../bitbake (where 'bitbake' must be created manually after cloning the project), you can have now | . | |-- build/ | `-- sources/ | |-- bitbake/ | `-- org.openembedded.core/ which is completely managed by 'git'. Patch adds $OEROOT/.. to the search path for 'bitbake' (From OE-Core rev: 5b3afc9cfe38a9fb435fbe5fcabc59b9a60f4657) Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-02-24buildhistory-diff: honour report_all flagAnuj Mittal
Make sure that we're passing a bool value. Without this, buildhistory shows all the output for all the keys/fields when it shouldn't be by default. (From OE-Core rev: b30153a15715a83c0f9a7d7d1883a15404992a19) Signed-off-by: Anuj Mittal <anuj.mittal@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-02-20scripts/contrib/build-perf-test: Fix fetchall reference to use runallRichard Purdie
(From OE-Core rev: 028ab7eb11f78c02900389197eace81824e6553f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-02-16oe-pkgdata-util: add --long option to list-pkg-files to show sizesRoss Burton
(From OE-Core rev: 1f3a5acb825a9f707c1ab780131e009f9ce21451) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-02-06devtool: set up git repos so that singletask.lock is ignoredPaul Eggleton
singletask.lock is written out while certain tasks execute for recipes that have externalsrc.bbclass enabled - this includes recipes in devtool's workspace. It appears that there's a race where singletask.lock will be there one minute and then when we try to get the file checksum of it (since we want to know if anything in the source tree has changed) it will be gone, and git chokes. To fix that, add singletask.lock to .git/info/exclude in the repository, regardless of whether we created the repository or not. In any case singletask.lock should never be tracked by git, so this is a good thing to be doing for that reason as well. This fixes oe-selftest failures in test_devtool_modify that we've seen on the Yocto Project autobuilder: bb.data_smart.ExpansionError: Failure expanding variable do_compile[file-checksums], expression was ${@srctree_hash_files(d)} which triggered exception CalledProcessError: Command '['git', 'add', '-A', '.']' returned non-zero exit status 128. Note that this only fixes this issue for devtool; if you are using externalsrc independently of devtool there's a chance this will still be an issue unless you add singletask.lock to your .gitignore. (From OE-Core rev: 334ba846c795fc0d8c73ce05a1b0882739c86650) 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>
2018-01-30postinst_intercepts: add a delay_to_first_boot hookAlexander Kanavin
This allows postinsts scripts to explicitly request a deferral to first boot (by calling 'postinst_intercept delay_to_first_boot') instead of 'exit 1' which should be used only to indicate actual script failures. (From OE-Core rev: 853ac4a061e47c70b61e255c3cf6109d2058d2cc) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-01-29distrodata: add a utility script to compare list of recipesTan Shen Joon
distrocompare.sh is added to compare the added list of recipes between two releases. The output of the script will share the information of the licenses required and other distributions that are using the package. If a single input is provided, it will compare the current branch with the provided branch/commit-ish package list. To run : distrocompare.sh <older hash> <newer hash> E.g. distrocompare.sh morty 92aa0e7 E.g. distrocompare.sh morty pyro E.g. distrocompare.sh morty output : The script will produce a file ending with new_recipe_list.txt preceeded by the branch name from input (From OE-Core rev: 32b363c2ba91fde4f10e5fe2c898b2fc2702aa85) Signed-off-by: Tan Shen Joon <shen.joon.tan@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-01-29oe-pkgdata-util: Include colon when searching for variablesAmanda Brindle
When searching for variables, include colon to ensure the script doesn't find a variable that starts with the same name. (From OE-Core rev: 3d2c87c4f4115b01534ab198c27682c7e4c5f31f) Signed-off-by: Amanda Brindle <amanda.r.brindle@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-01-22oe-pkgdata-util: Add support for RPROVIDESAmanda Brindle
In lookup_recipe, package_info, and list_pkg_files, check if the package name exists in runtime-rprovides. If so, and the provider package has a different name than the inputted package, print a note that says the specified package is in another package's RPROVIDES. If the provider package has the same name as the inputted package, continue as before. Fixes [YOCTO 11943] (From OE-Core rev: f78478f0d0379ea02727c81ad2455207c70d140b) Signed-off-by: Amanda Brindle <amanda.r.brindle@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-01-22oe-pkgdata-util: Refactor functions for consistencyAmanda Brindle
Refactor functions lookup_recipe and package_info to be consistent with list_pkg_files. Print the appropriate information as soon as it's found, rather than storing it in a mappings variable and wait to print after searching all packages. (From OE-Core rev: 64d3ce83d5c48d479709b4c1355e23b3768493fb) Signed-off-by: Amanda Brindle <amanda.r.brindle@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-01-20python3: Restructure python3 packaging and replace it with autopackagingAlejandro Hernandez
See previous commit (python2 version) for more info, since mostly everything applies here as well. Old manifest file had several issues: - Its unorganized and hard to read and understand it for an average human being. - When a new package needs to be added, the user actually has to modify the script that creates the manifest, then call the script to create a new manifest, and then submit a patch for both the script and the manifest, so its a little convoluted. - Git complains every single time a patch is submitted to the manifest, since it violates some of its guidelines. - It changes or may change with every release of python, its impossible to know if the required files for a certain package have changed (it could have more or less dependencies), the only way of doing so would be to install and test them all one by one on separate individual images, and even then we wouldnt know if they require less dependencies, we would just know if an extra dependency is required since it would complain, lets face it, this isnt feasible. - The same thing happens for new packages, if someone wants to add a new package, its dependencies need to be checked manually one by one. Features/Fixes: - A new manifest format is used (JSON), easy to read and understand. This file is parsed by the python recipe and python packages read from here are passed directly to bitbake during parsing time. - It provides an automatic manifest creation task (explained on previous commit), which automagically checks for every package dependencies and adds them to the new manifest, hence we will have on each package exactly what that package needs to be run, providing finer granularity. - Dependencies are also checked automagically for new packages (explained on previous commit). This patch has the same features as the python2 version but it differs in the following ways: - Python3 handles precompiled bytecode files (*.pyc) differently. for this reason and since we are cross compiling, wildcards couldnt be avoided on python3 (See PEP #3147 [1]). Both the manifest and the manifest creation script handle this differently, the manifest for python3 has an extra field for cached files, which is how it lets the user install the cached files or not via : INCLUDE_PYCS = "1" on their local.conf. - Shared libraries nomenclature also changed on python3, so again, we use wildcards to deal with this issue ( See PEP #3149 [2]): - Fixes python3 manifest, python3-core should be base and everything should depend on it, hence several packages were deleted: python3-enum, re, gdbm, subprocess, signal, readline. - When building python3-native it adds as symlink to it called nativepython3, which is then isued by the create_manifest task. - Fixes [YOCTO #11513] while were at it. References: [1] https://www.python.org/dev/peps/pep-3147/ [2] https://www.python.org/dev/peps/pep-3149/ (From OE-Core rev: 54ac820b8a639950ccb534dcd9d6eaf8b2b736e0) Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-01-20python: Restructure python packaging and replace it with autopackagingAlejandro Hernandez
The reason we have a manifest file for python is that our goal is to keep python-core as small as posible and add other python packages only when the user needs them, hence why we split upstream python into several packages. Although our manifest file has several issues: - Its unorganized and hard to read and understand it for an average human being. - When a new package needs to be added, the user actually has to modify the script that creates the manifest, then call the script to create a new manifest, and then submit a patch for both the script and the manifest, so its a little convoluted. - Git complains every single time a patch is submitted to the manifest, since it violates some of its guidelines. - It changes or may change with every release of python, its impossible to know if the required files for a certain package have changed (it could have more or less dependencies), the only way of doing so would be to install and test them all one by one on separate individual images, and even then we wouldnt know if they require less dependencies, we would just know if an extra dependency is required since it would complain, lets face it, this isnt feasible. - The same thing happens for new packages, if someone wants to add a new package, its dependencies need to be checked manually one by one. This patch fixes those issues, while adding some additional features. Features/Fixes: - A new manifest format is used (JSON), easy to read and understand. This file is parsed by the python recipe and python packages read from here are passed directly to bitbake during parsing time. - It provides an automatic manifest creation task (explained below), which automagically checks for every package dependencies and adds them to the new manifest, hence we will have on each package exactly what that package needs to be run, providing finer granularity. - Dependencies are also checked automagically for new packages (explained below). - Fixes the manifest in the following ways: * python-core should be base and all packages should depend on it, fixes lang, string, codecs, etc. * Fixes packages with repeated files (e.g. bssdb and db, or netclient and mime, and many others). - Sitecustomize was fixed since encoding was deprecated. - The JSON manifest file invalidates bitbake's cache, so if it changes the python package will be rebuilt. - It creates a solution for users that want precompiled bytecode files (*.pyc) INCLUDE_PYCS = "1" can be set by the user on their local.conf to include such files, some argument they get faster boot time, even when the files would be created on their first run?, but they also sometimes give a magic number error and take up space, so we leave it to the user to decide if they want them or not. - Fixes python-core dependencies, e.g. When python is run on an image, it TRIES to import everything it needs, but it doesnt necessarily fails when it doesnt find something, so even if we didnt know, we had errors like (trimmed on purpose): # trying /usr/lib/python2.7/_locale.so # trying /usr/lib/python2.7/lib-dynload/_locale.so # trying /usr/lib/python2.7/_sysconfigdata.so while it didnt complain about _locale it should have imported it, after creating a new manifest with the automated script we get: # trying /usr/lib/python2.7/lib-dynload/_locale.so dlopen("/usr/lib/python2.7/lib-dynload/_locale.so", 2); import _locale # dynamically loaded from /usr/lib/python2.7/lib-dynload/_locale.so How to use (after a new release of python, or maybe before every OE release): - A new task called create_manifest was added to the python package, which may be invoked via: $ bitbake python -c create_manifest This task runs a script on native python on our HOST system, and since the python and python-native packages come from the same source, we can use it to know the dependencies of each module as if we were doing it on an image, this script is called create_manifest.py and in a very simplistic way it does the following: 1. Reads the JSON manifest file and creates a dictionary data structure with all of our python packages, their FILES, RDEPENDS and SUMMARY. 2. Loops through all of them and runs every module listed on them asynchronously, determining every dependency that they have. 3. These module dependencies are then handled, to be able to know which packages contain those files and which should RDEPEND on one another. 4. The data structure that comes out of this, is then used to create a new manifest file which is automatically copied onto the user's python directory replacing the old one. Create_manifest script features: - Handles modules which dont exist anymore (new release for example). - Handles modules that are builtin. - Deals with modules which were not compiled (e.g. bsddb or ossaudiodev) - Deals with packages which include folders. - Deals with packages which include FILES with a wildcard. - The manifest can be constructed on a multilib environment as well. - This method works for both python modules and shared libraries used by python. How to add a new package: - If a user wants to add a new package all that has to be done is modify the python2-manifest.json file, and add the required file(s) to the FILES list, the script should handle all the rest. Real example: We want to add a web browser package, including the file webbrowser.py which at the moment is on python-misc. "webbrowser": { "files": ["${libdir}/python2.7/lib-dynload/webbrowser.py"], "rdepends": [], "summary": "Python Web Browser support"} Run bitbake python -c create_manifest and the resulting manifest should be completed after a few seconds, showing something like: "webbrowser": { "files": ["${libdir}/python2.7/webbrowser.py"], "rdepends": ["core","fcntl","io","pickle","shell","subprocess"], "summary": "Python Web Browser support"} Known errors/issues: - Some special packages are handled differently: core, misc, modules,dev, staticdev. All these should be handled manually, because they either include binaries, static libraries, include files, etc. (something that we cant import). Specifically static libraries are not not supported by this method and have to be handled by the user. - The change should be transparent to the user, other than the fact that now we CANT build python-foo (it was pretty dumb anyway, since what building python-foo actually did was building the whole python package anyway), but doing IMAGE_INSTALL_append = " python-foo" would create an image with the requested package with no issues. [YOCTO #11510] [YOCTO #11694] [YOCTO #11695] (From OE-Core rev: 6959e2e4dba5bbfa6ffd49c44e738cc1c38bc280) Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-01-19scripts/oe-depends-dot: add it to handle dot filesRobert Yang
Add it to handle recipe-depends.dot and task-depends.dot. E.g.: * Print why rpm is built $ oe-depends-dot -k rpm --why/-w recipe-depends.dot Because: core-image-sato libdnf libsolv dnf * Print bzip2-native's depends $ oe-depends-dot -k bzip2-native --depends/-d recipe-depends.dot Depends: automake-native gnu-config-native libtool-native quilt-native autoconf-native * Remove duplicated dependencies to reduce the size of the dot files. For example, A->B, B->C, A->C, then A->C can be removed. The dot files are too big, we nearly couldn't use 'dot -T' to generate pictcures for target recipes, remove the duplicated dependencies makes is it possible. $ bitbake core-image-sato -g $ oe-depends-dot -r recipe-depends.dot Saving reduced dot file to recipe-depends-reduced.dot $ du -sh recipe-depends*.dot 608K recipe-depends.dot 32K recipe-depends-reduced.dot It has been recuded from 608K to 32K, now we can generate a picture, otherwise, it is too big: $ dot -Tpng recipe-depends-reduced.dot -O It also can handle task-depends.dot. (From OE-Core rev: 7dc7860691304d63e7ad728d2180474906fe0a5c) 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>
2018-01-18contrib/yocto-bsp-kernel-update.sh: remove this scriptYi Zhao
This script was unused since yocto-bsp tool had been removed. (From meta-yocto rev: 594ced59dc80c11d573ae4a16e1aff910a8d9300) Signed-off-by: Yi Zhao <yi.zhao@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-01-18buildhistory-diff: add support for colourising the outputRoss Burton
Colour value removes in red and additions in green, making it easier to scan the output for relevant changes. This adds a --colour option to specify whether colouring should be on, off, or detected. The default is detected, and depends on whether stdout is a TTY (same behaviour as git). (From OE-Core rev: 4208f1546c92f069e432d1865269ce539db8cea7) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-01-18devtool: rename the suggested license change tag to 'License-Update:'Alexander Kanavin
(From OE-Core rev: 3905ae20330f204f3c8997e2d5aaf15dcf5a860c) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-01-14wic: if we can't get from ioctl, try from os.stat()Dogukan Ergun
Under some conditions, ioctl FIGETBSZ can't return real value. We can try to use fallback via os.stat() to get block size. Source of patch: https://github.com/intel/bmap-tools/commit/17365f4fe9089df7ee9800a2a0ced177ec4798a4 (From OE-Core rev: d8f7cf2d38934c248be91101236f7537d0d31ea7) Signed-off-by: Dogukan Ergun <dogukan.ergun@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-01-13scripts/wic: explicitly set BUILDDIR within eSDKChang Rebecca Swee Fun
When we run wic within eSDK: $ wic create mkefidisk -e core-image-minimal ERROR: BUILDDIR not found, exiting. (Did you forget to source oe-init-build-env?) In order to figure out variable values, one must have sourced the OE build environment setup script. However, when we are in within the eSDK environment which isn't initialised like the normal OE build environment, we can't use wic utility with eSDK. Reference: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#wic-requirements While wic ought to be fixed to be able to run without bitbake & native tools [YOCTO #11281], but this is a workaround to set BUILDDIR in the environment so that bitbake environment is setup for wic to build its required native tools. (From OE-Core rev: 03fa13a269d2887cc5d13fd474fb39a2be037f2c) Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-01-13scripts/wic: fix error of import wic module in eSDK environmentChang Rebecca Swee Fun
wic modules in scripts/lib/ are needed for wic to work, but path to the python module is not exported in eSDK environment and we were using an absolutized path of wic script within the sysroots. We now changed to use real script path instead, where the wic modules are located. This will also resolved the tracebacks found when running wic from within the eSDK environment. Traceback (most recent call last): File "/tmp/deploy/sdk/poky_sdk/sysroots/x86_64-pokysdk-linux/usr/bin/wic", line 58, in <module> from wic import WicError ImportError: No module named 'wic' (From OE-Core rev: dcea30b885797ece3439cf1201795a975628d664) Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-01-13scripts/wic: append bitbake executable file path in eSDK environmentChang Rebecca Swee Fun
wic needs a set of tools to be available from sysroots. wic will find bitbake executable within the environment, and wic was unable to locate bitbake executable within eSDK because it wasn't setup with the OE build environment script. Hence, we need to add bitbake file path into the environment PATH for wic to be able to discover it and import bb modules. (From OE-Core rev: 89df0d31c9dd22ceba4c95a2a56ca78e58d871a8) Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit 1.2.3-korg (git 2.39.0) at 2024-05-03 01:23:54 +0000