summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb
Commit message (Collapse)AuthorAgeFilesLines
...
* bitbake: knotty: Fix row/column function return value issueRichard Purdie2015-12-181-1/+1
| | | | | | | | | | | | | When the row handling was introduced, one of the callbacks was missed resulting in: TypeError: can only concatenate tuple (not "int") to tuple Fix it. (Bitbake rev: 0b77cea2bf5b5f5704e2650fb0332f5d78037781) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: buildinfohelper: Update for buildstats layout changeRichard Purdie2015-12-181-5/+3
| | | | | | | | This updates buildinfo helper for the recent buildstats layout change (Bitbake rev: 30311bbe667e9f22de17fae00ff58da06a7c3e23) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch: use orig localpath when calling orig methodChristopher Larson2015-12-181-1/+1
| | | | | | | | | | | | | | | | When a mirror tarball is fetched, the original fetch method is called, which unpacks the mirror tarball. After the original method is called, it checks the localpath of the mirror tarball rather than the clone path, which isn't ideal, particularly if the mirror tarball was removed due to being out of date. We know the original fetch method will do what it needs to do to get its content in the form it needs from the mirror tarball, so we can use its localpath instead. (Bitbake rev: 1732ad65d6c7d67b7d07cb30c074f5016adadbea) Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Awais Belal <awais_belal@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: utils: Improve traceback from better_exec internal errorsRichard Purdie2015-12-181-2/+4
| | | | | | | | | | If you break the internals of better_exec(), you get a very weird error about tb_next not being a method of None. Fix this by checking we can step back a trace level. (Bitbake rev: 1d710ed484f68fca0789022dde7ba877b9a894f5) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: ast/event/utils: Improve tracebacks to include file and line ↵Richard Purdie2015-12-185-14/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | numbers more correctly Currently bitbake tracebacks can have places where the line numbers are inaccurate and filenames may be missing. These changes start to try and correct this. The only way I could find to correct line numbers was to compile as a python ast, tweak the line numbers then compile to bytecode. I'm open to better ways of doing this if anyone knows of any. This does mean passing a few more parameters into functions, and putting more data into the data store about functions (i.e. their filenames and line numbers) but the improvement in debugging is more than worthwhile). Before: ---------------- ERROR: Execution of event handler 'run_buildstats' failed Traceback (most recent call last): File "run_buildstats(e)", line 43, in run_buildstats(e=<bb.build.TaskStarted object at 0x7f7b7c57a590>) NameError: global name 'notexist' is not defined ERROR: Build of do_patch failed ERROR: Traceback (most recent call last): File "/media/build1/poky/bitbake/lib/bb/build.py", line 560, in exec_task return _exec_task(fn, task, d, quieterr) File "/media/build1/poky/bitbake/lib/bb/build.py", line 497, in _exec_task event.fire(TaskStarted(task, logfn, flags, localdata), localdata) File "/media/build1/poky/bitbake/lib/bb/event.py", line 170, in fire fire_class_handlers(event, d) File "/media/build1/poky/bitbake/lib/bb/event.py", line 109, in fire_class_handlers execute_handler(name, handler, event, d) File "/media/build1/poky/bitbake/lib/bb/event.py", line 81, in execute_handler ret = handler(event) File "run_buildstats(e)", line 43, in run_buildstats NameError: global name 'notexist' is not defined ---------------- After: ---------------- ERROR: Execution of event handler 'run_buildstats' failed Traceback (most recent call last): File "/media/build1/poky/meta/classes/buildstats.bbclass", line 143, in run_buildstats(e=<bb.build.TaskStarted object at 0x7efe89284e10>): if isinstance(e, bb.build.TaskStarted): > trigger = notexist pn = d.getVar("PN", True) NameError: global name 'notexist' is not defined ERROR: Build of do_package failed ERROR: Traceback (most recent call last): File "/media/build1/poky/bitbake/lib/bb/build.py", line 560, in exec_task return _exec_task(fn, task, d, quieterr) File "/media/build1/poky/bitbake/lib/bb/build.py", line 497, in _exec_task event.fire(TaskStarted(task, logfn, flags, localdata), localdata) File "/media/build1/poky/bitbake/lib/bb/event.py", line 170, in fire fire_class_handlers(event, d) File "/media/build1/poky/bitbake/lib/bb/event.py", line 109, in fire_class_handlers execute_handler(name, handler, event, d) File "/media/build1/poky/bitbake/lib/bb/event.py", line 81, in execute_handler ret = handler(event) File "/media/build1/poky/meta/classes/buildstats.bbclass", line 143, in run_buildstats trigger = notexist NameError: global name 'notexist' is not defined ---------------- (Bitbake rev: 1ff860960919ff6f8097138bc68de85bcb5f88b0) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Add support for <task>- syntaxRichard Purdie2015-12-181-8/+18
| | | | | | | | | | | It can be useful to run all tasks up to but not including a specific task. The main reason this was never added was the lack of a good syntax. This patch uses the syntax <taskname>- to denote this behaviour which is simple, not invasive and fits what we need from good syntax IMO, hence we can add this. (Bitbake rev: 99ccfd411ab3f7baa111f9f3d50fae68816a9a83) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: Start Django machinery for database accessElliot Smith2015-12-141-0/+3
| | | | | | | | | | | | | | | | | | buildinfohelper, with the new import paths for our Django models and Django 1.8, was not getting an active connection to the database. In buildinfohelper, call django.setup() explicitly to make sure that the database connection is ready and models can be queried and saved. [YOCTO #8364] (Bitbake rev: 671aaab8cb7c494cd5c7621b45a6f41a203d8bb5) Signed-off-by: Elliot Smith <elliot.smith@intel.com> Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: brian avery <avery.brian@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: Create default project with get_or_create* methodElliot Smith2015-12-141-2/+7
| | | | | | | | | | | | | | | | Rather than maintain data as part of the migrations (as was done for the default project previously), create the default (cli builds) project on demand as a by-product of getting it from the database. [YOCTO #8364] (Bitbake rev: 5fd8e90ab9b81d1bd0d301bc1c91228ecbbea74b) Signed-off-by: Elliot Smith <elliot.smith@intel.com> Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: brian avery <avery.brian@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: Fix references to app pathsEd Bartosh2015-12-141-8/+8
| | | | | | | | | | | | | | | | | | | | | | The buildinfohelper runs outside of Django, but still needs access to our Django app classes. Previously, the imports referenced the toaster.* app, which worked fine. But in Django 1.8, this causes an error about the same module being loaded multiple times from different paths. Change the paths to our Django modules so they don't cause this error to be thrown. We can do this as we've added our application libraries to sys.path in the buildinfohelper anyway. [YOCTO #8364] (Bitbake rev: 070da64cf32c32b5ffc34d611b463c3a3960b419) Signed-off-by: Elliot Smith <elliot.smith@intel.com> Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: brian avery <avery.brian@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toasterui: process SetBRBE eventEd Bartosh2015-12-141-0/+2
| | | | | | | | | | | | | | | | | Currently BRBE is known to toasterui only when build is started. It's passed to it with BuildStarted event. This is too late as if build fails earilier than build starts toasterui can not inform Toaster about the failure. Set BRBE as soon as it's provided by Toaster. This should make toasterui to be able to inform Toaster about early build failures, e.g. failures during recipe parsing. (Bitbake rev: d7819508dac488a64be3caec88db285cda9599ab) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Michael Wood <michael.g.wood@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: event: Fix subprocess event error traceback failuresRichard Purdie2015-12-141-0/+2
| | | | | | | | | | | | | | | | | | If subprocess raises a CalledProcessError() error, e.g. from a call like subprocess.check_call("false"), bitbake would try and pass the object over IPC and fail, leading to an unusual error: ('__init__() takes at least 3 arguments (1 given)', <class 'subprocess.CalledProcessError'>, ())% To avoid this, we turn the value into a string which prevents the issues the IPC has trying to deal with the object (for the same reason we deal with tracebacks here too). [YOCTO #8752] (Bitbake rev: 05695424b918fc81b16cbac70d79d8271a0b6045) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: toasterui Add ParseStarted/ParseProgress events to maskbrian avery2015-12-091-2/+12
| | | | | | | | | | | | | | | | Toaster is not able to see ParseStarted and ParseProgress events for command-line builds. This means it's not possible for Toaster to detect failed builds, if the failure occurs at a point before the BuildStarted event, as the build won't show up at all. Add these events to the event mask, so that Toaster's toasterui can detect and respond to them. (Bitbake rev: 16bfd3e3d145705a2b3a05648ddbcacc7a338dfa) Signed-off-by: brian avery <avery.brian@gmail.com> Signed-off-by: Elliot Smith <elliot.smith@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: Enforce terminal line limit to stop crazy scrollingRichard Purdie2015-12-081-3/+4
| | | | | | | | | | | | | | | | If there are more tasks running than there are lines on the terminal, the data scrolls in ways the UI wasn't designed for. This patch adjusts the UI just to show the processes which fit onto the number of rows in the terminal window. You can see the total number running from the counter in the top left as usual and this makes warning and errors messages scrolling from the top of the window work as designed. Ultimately, scrolling would be nice but is for another time, this fixes the biggest UI issue on highly parallel machines. (Bitbake rev: 67b77658e2bfa849f6f55c9c262cb11d6bfdb399) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: rename REGEX, REGEX_URI, and GITTAGREGEX.Alexander Kanavin2015-12-083-8/+8
| | | | | | | | | | | | Rename REGEX to UPSTREAM_CHECK_REGEX, REGEX_URI to UPSTREAM_CHECK_URI, and GITTAGREGEX to UPSTREAM_CHECK_GITTAGREGEX to better reflect their purpose and to reflect a common namespace. (Bitbake rev: f0a9e783f9969573fd74edfa241ef14f18ac684e) 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>
* bitbake: toaster: get rid of complicated heuristicsEd Bartosh2015-12-071-38/+9
| | | | | | | | | | | | | | | | | | Removed buildinfohelper code which was trying to guess layer version of the recipe using build request information. The code caused creation of duplicated recipes as it resulted in layer version from layer index instead of returning build layer version. As a result of this Toaster UI was not showing any information about recipes. Default approach used to find layer version seems to work much better as it finds proper layer version. Now toaster will use it as the only way to find layer version. (Bitbake rev: 101690bda7ad55dc0657483233c90c374713755b) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: brian avery <avery.brian@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: buildinfohelper Broaden the toaster created recipe data caseMichael Wood2015-12-071-4/+3
| | | | | | | | | | | | | | | | When build information is the 'original' source of the information we need to return the recipe that was created rather than the copy of the recipe that is taken for keeping build history. We do this already for command line triggered builds, but we also have this case for custom images. We can simply check if the built_recipe exists instead of special casing this. (Bitbake rev: 9a8653bf602b2111dee7ee6a459682a68a695b22) Signed-off-by: Michael Wood <michael.g.wood@intel.com> Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: brian avery <avery.brian@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: do not create duplicate HelpText objectsEd Bartosh2015-12-071-7/+3
| | | | | | | | | | | | | | | | | buildinfohelper code expects only one HelpText object per build/variable/description. Current code creates more than one such an object, which causes toastergui to crash with this exception: MultipleObjectsReturned: get() returned more than one HelpText -- it returned 2! Used git_or_create API to ensure that only one HelpText object is created. (Bitbake rev: e9b46803eb6f1f4044919abf90c8aeb3536e73ed) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: brian avery <avery.brian@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: do not terminate bb serverEd Bartosh2015-12-071-9/+5
| | | | | | | | | | | | | | | Toaster needs bb server to be running all the time due to merged analysis and managed modes. Server gets restarted before every build triggered by UI, but it shouldn't be terminated as it will influence command line builds. [YOCTO #8279] (Bitbake rev: e69c87c7842e796ffcd7193ecde22c8f688498f5) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: brian avery <avery.brian@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: update brbe and project attributesEd Bartosh2015-12-071-0/+6
| | | | | | | | | | | | Updated attributes of buildinfohelper object as they can be changed for every build. For example brbe is set by runbuilds for every build triggered by Toaster UI. (Bitbake rev: ea3bc8d01704dc64f6cb7b4f5fe66c312a575174) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: brian avery <avery.brian@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib/bb/utils: improve edit_bblayers_conf() handling of ↵Paul Eggleton2015-12-072-14/+267
| | | | | | | | | | | | | | | | | | | | | | bblayers.conf formatting Make the following improvements to edit_bblayers_conf(): * Support ~ in BBLAYERS entries * Handle where BBLAYERS items are added over multiple lines with += instead of one single long item Also add some comments documenting the function arguments and return values as well as a set of bitbake-selftest tests. (This function is used by the bitbake-layers add, remove and layerindex-fetch subcommands, as well as devtool when adding the workspace layer). (Bitbake rev: e9a0858023c7671e30cc8ebb08496304b7f26b31) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib/bb/utils: fix error in edit_metadata() when deleting first linePaul Eggleton2015-12-071-1/+1
| | | | | | | | | | | | If you tried to delete the variable on the first line passed to edit_metadata() this failed because the logic for trimming extra blank lines didn't expect the list to be empty at that point - fix that bad assumption. (Bitbake rev: 8bce6fefdc5c046b916588962a2b429c0f648133) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: wget.py: parse only <a> tagsAlexander Kanavin2015-12-071-2/+3
| | | | | | | | | | | | | | | For two reasons: 1) The important one: we hit the following bug when doing upstream version checks on some webpages: https://bugs.launchpad.net/beautifulsoup/+bug/1471755 2) Also, documentation for beautifulsoup states that memory usage and speed is improved that way. (Bitbake rev: 7546d4aeb3ba8fda9832081b84d93138dc5e58d6) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data_smart: Only support lowercase OVERRIDESRichard Purdie2015-11-161-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our current OVERRIDES handling means we end up caching and checking for a lot of possible override combinations which turn out to very unlikely. A typical example is the SRC_URI variable where we have to check if "URI" is an override. Having spent many hours working in this code, I've realised all the actual overrides we use are lower case and our standard variables are mostly uppercase. This means we could gain quite some speed advantage if we write this into the code, that overrides only consist of lowercase characters. This patch shows how simple this is and the resulting speed gains are significant. This is a significant change but tests show we don't appear to have any users of capitals in overrides in any OE-Core metadata. Before "time bitbake -p": real 2m4.224s user 7m32.312s sys 0m7.116s After "time bitbake -p": real 1m26.009s user 5m10.484s sys 0m4.640s This check could also be made conditional however I'm not seeing a need to do that at present. (Bitbake rev: c9b9443faa76ee7366b1400a56f826f3f9dec1be) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2: Remove crazy code in unpackRichard Purdie2015-11-161-3/+0
| | | | | | | | | | This looks reasonable until you realise self.localpath is a function. Data expansion of something which isn't a string is the original value so this code just wastes CPU cycles and makes no sense. Remove it. (Bitbake rev: 37214ea9bf484998b75dbc1200d53f1afc5257ed) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: parse: Don't try to expand __base_depends/__dependsRichard Purdie2015-11-161-2/+2
| | | | | | | | Trying to expand a variable which isn't a string doesn't make sense. (Bitbake rev: 62367cca1f1793eb9827406bcdd5980fdeb80a60) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cache: Don't try to expand __inherit_dataRichard Purdie2015-11-161-3/+3
| | | | | | | | Trying to expand a variable which isn't a string doesn't make sense. (Bitbake rev: 54d0ddd166a6707b4f8c8535639e3055b783363b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: codeparser: Only load the codeparser cache onceRichard Purdie2015-11-161-0/+4
| | | | | | | | | | The server state gets reset multiple times during startup and currently we reload the codeparser cache each time. This is pointless and causes unnecessary interaction time with bitbake. (Bitbake rev: 4f700316933e8e7b2d27366e5ce6176895b913e7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toasterui: Create per-build logsElliot Smith2015-10-292-30/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rather than relying on bug 8411, which is conveniently creating separate log files for each of our builds, create our own log file for each build. The log files are created in the same tmp directories that bitbake users, but are timestamped to the millisecond to avoid name collisions. Each log file is opened on a ParseStarted event (for builds triggered by Toaster) or BuildStarted event (for builds on the command line: Toaster doesn't get the ParseStarted event for command-line builds). The log file is closed on the BuildCompleted event, or if the build fails. Because we start logging on ParseStarted for Toaster builds, we're able to capture the "Build Configuration" section which bitbake writes to output. [YOCTO #8373] (Bitbake rev: 7974203cd8bc66dff1fcc55f8723dedefaf72840) Signed-off-by: Elliot Smith <elliot.smith@intel.com> Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: build/utils: Add BB_TASK_IONICE_LEVEL supportRichard Purdie2015-10-292-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Similarly to BB_TASK_NICE_LEVEL, add BB_TASK_IONICE_LEVEL which allows the ioprio of tasks to be adjusted. This is in response to various qemu runtime timeouts which have been witnessed on the autobuilder, seemingly due to IO starvation (we already use NICE_LEVEL to adjust tasks). This has a fairly urgent need to deal with certain 'random' failures we're seeing on the autobuilders in testing. The format of the data in the variable is BB_TASK_IONICE_LEVEL = "<class>.<prio>". For <class>, 2 is best effort (the default), 1 is real time and 3 is idle. You'd need superuser privileges to use realtime. The <prio> value is a default of 4, and can be set between 0 and 7 with 7 being lowest priority and 0 the highest. The user can set this freely with normal privileges Note that in order for this to take effect, you need the cfq scheduler selected for the backing block device. We could use nice wrapper functions for ioprio from modules like psutil however that would complicate bitbake dependencies. This version has some magic numbers but works on the main 32 and 64 bit x86 build architectures and can easily be extended if ever needed. When we move to python 3.x, we can likely replace this with standard calls. (Bitbake rev: b9471ad147b102c45d65f5ffd9521864df7ff9c1) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Ensure BB_CONSOLE remains correct over server resetsRichard Purdie2015-10-291-0/+7
| | | | | | | | | | The console log data is written to is created at console initialisation time and does not change over reset events. This ensures the BB_CONSOLELOG value is correct over such resets by preserving it. (Bitbake rev: 335eb2db228f7543a49de71f063ac72b865c947a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bb/ui: Use getSetVariable command for BB_CONSOLELOGRichard Purdie2015-10-292-2/+2
| | | | | | | | | | | | | | | | | | | | Metadata can define BB_CONSOLELOG as containing ${DATETIME} and this can get expanded to a different value each time the variable is read. In the case of BB_CONSOLELOG, this behaviour is not desireable. The values of DATE/TIME are locked down at build time but this is too late for the purposes of ensuring the system can figure out the real value of BB_CONSOLELOG. The best way to do this is to set the variable into the datastore, thereby preserving its value. [YOCTO #8411] (Bitbake rev: 021f2eb55ab5863b57ed1b3f19f1b329bc1ad477) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: command: Add getSetVariable commandRichard Purdie2015-10-291-0/+10
| | | | | | | | | | There are some use cases where we want to read a variable but also set the variable to the value read, effectively locking in any expansion of it. This adds such a command. (Bitbake rev: 0c0c524691e3d2ffd9953a106fcc06262cbde910) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: add get_or_create_targets APIEd Bartosh2015-10-271-15/+21
| | | | | | | | | | | | | | | | | Target objects are created before the build if build is started from UI in build mode. However, in analysis mode Target objects don't exist and need to be created using information from bitbake events. Added new API call get_or_create_targets to retrive existing target objects or create them if they don't exist yet. (Bitbake rev: ef69be31d133696bde54605f5a18da660099734c) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Elliot Smith <elliot.smith@intel.com> Signed-off-by: brian avery <avery.brian@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetcher: svn: Add support for checkout to a custom pathJens Rehsack2015-10-271-2/+7
| | | | | | | | | | | Add support for the Subversion fetcher to checkout modules to a custom path than the module name to avoid checkout is always module - svn is path based and tag/branch-checkout might break builds because of invaid path specs. (Bitbake rev: af88f538e61afa1b115be4d7afe00d8477f61750) Signed-off-by: Jens Rehsack <sno@netbsd.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: preserve pre and post configsEd Bartosh2015-10-273-0/+14
| | | | | | | | | | | | | | | | | | | Additional config files passed to bitbake server with --read and --postread options are rewritten by client bitbake even if it doesn't use those options. This is a show stopper for toaster as toaster command line builds are based on the assumption that server is aware of toster configs, provided by --postread option. This behaviour is fixed by preserving values of --read and --postread options when bitbake server starts and restoring them if client bitbake doesn't explicitly specify them. (Bitbake rev: 02c64f7487ca8ec5d32c440f5002c4b8f64b76a6) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2/hg: Include missing errno importLogan Buchy2015-10-161-0/+1
| | | | | | | | | | errno.ENOENT checked if deletion of the fullmirror fails. Exception was thrown since module not imported (Bitbake rev: d92ebfc34b69ad5df2d151e6b8299fbb5afa3e5f) Signed-off-by: Logan Buchy <logan.buchy@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: normalize build targetsEd Bartosh2015-10-161-1/+19
| | | | | | | | | | | | | | | BuildStarted event not fully represents build tasks for the targets. If -c option is used to specify default task it's not included into the event. Made build targets to always look as <target>:do_<task>. Consider default task (do_build or specified by -c command line option) when normalizing. (Bitbake rev: 0b0e214e6f53c97ad3d48f622c7fc0ca149956f6) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: Record critical errorsElliot Smith2015-10-162-1/+6
| | | | | | | | | | | | | | | | | | | | Critical errors (where a build failed for reasons of misconfiguration, such as a machine being specified which is not in a project's layers) were being ignored (only log records up to ERROR level were being logged to Toaster's db). This meant that the build would fail but would not correctly report why. Add support for CRITICAL error levels to the LogMessage model, include errors at this level in the errors property for a build, and show errors at this level in the build dashboard. [YOCTO #8320] (Bitbake rev: b6eacbca9cacb607de864ab7d093deb296da8226) Signed-off-by: Elliot Smith <elliot.smith@intel.com> Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: buildinfohelper Detect command line buildsMichael Wood2015-10-161-12/+22
| | | | | | | | | | | | When we're building using toaster as just a listener to bitbake (analysis mode) we need to handle the case where the toaster configuration data isn't present so we don't need to try and update the existing information. (Bitbake rev: a22faae2c3a5948356ce3cbc73c34509de65d370) Signed-off-by: Michael Wood <michael.g.wood@intel.com> Signed-off-by: Elliot Smith <elliot.smith@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: buildinfohelper Skip packages we have no build info aboutMichael Wood2015-10-111-11/+31
| | | | | | | | | | | | | | | If there are more packages listed as installed than we know about from bitbake, and therefore have insufficient information to be able to create a Toaster Package object then skip it. Also handle the case where a dependency references such a package. Also clarify the error logging. (Bitbake rev: b4ce793685f70cab3f28cb4329aaaf3878cd62e8) Signed-off-by: Michael Wood <michael.g.wood@intel.com> Signed-off-by: Elliot Smith <elliot.smith@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: buildinfohelper associate build data with built_recipeMichael Wood2015-10-111-1/+2
| | | | | | | | | | | Make sure we associate build data with the built recipe rather than toaster's configuration copy of the recipe. (Bitbake rev: 34d4ef7289d72d151ad0acdccab8b99c8c31221e) Signed-off-by: Michael Wood <michael.g.wood@intel.com> Signed-off-by: Elliot Smith <elliot.smith@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: use meaningful logging levelsEd Bartosh2015-10-111-4/+4
| | | | | | | | | | Changed logging levels to more appropriate ones. (Bitbake rev: 27d0360d13af0c698bf3a224b3f0d415f17bb678) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Elliot Smith <elliot.smith@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: ignore ReachableStamps eventEd Bartosh2015-10-111-1/+2
| | | | | | | | | | | | Added ReachableStamps event to the list of known events to ignore. This should stop toaster throwing error message: ERROR: Unknown event: <bb.event.ReachableStamps> (Bitbake rev: cd4137e13af6964858640b78aa7fe6f1612be251) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Elliot Smith <elliot.smith@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake/lib: Update version to 1.28.0Richard Purdie2015-10-011-1/+1
| | | | | | (Bitbake rev: 3e63abc6977bd5ef52ccb4d3757536bd564dfd34) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Make it clear why nostamp tasks signatures don't matchRichard Purdie2015-10-011-1/+9
| | | | | | | | | | | | If you run bitbake-diffsigs against two differing sigdata files from nostamp tasks it shows no difference despite the differing checksum. Change the code so this shows up as a nostamp 'taint' and at least makes the issue clearer to the end user. (Bitbake rev: 97679d18955dadaa34f9450564e44da99984d140) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Add handling of virtual/xxx provider mappingsRichard Purdie2015-10-011-0/+9
| | | | | | | | | | | | This firstly prints debug messages which show how bitbake decided to resolve the virtual/xxx providers which is useful for debugging. If the siggen has a tasks_resolved() method, it calls this, passing in the mappings, allowing that to do things with the resolved names. (Bitbake rev: d473fc84acddfd69a7207affcd89f65ea2ecf730) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: taskdata: Add a function to return the virtual/ mapping dataRichard Purdie2015-10-011-0/+12
| | | | | | | | | | | | | When building an execution task graph, bitbake does resolve virtual/xxx namespaces into specific providers. This data isn't exported anywhere however. This adds a function so that runqueue can at least retrieve this data which can then be used by the system. (Bitbake rev: ce51a51482d0900060512b24503714a730d72266) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: Rename BBPKGS -> BBTARGETSRichard Purdie2015-10-011-2/+2
| | | | | | | | | | | | | | | | | | BBPKGS is a confusing name from before we tried to straighten out our terminology. Its also a mostly unknown variable that isn't in wide use. I've been asked about it recently and before people start relying more heavily on it, I'd like to rename it BBTARGETS which better describes what it does. Its not currently in the manuals, I'd prefer to document it under the better name. I've not provided any migration path for the variable since I believe its unused currently. It allows the targets to built to be specified from a conf file in addition to those on the commandline. (Bitbake rev: f60c6a2172bceeb5682dcb738a02c4bf26176566) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: utils: only add layer once in edit_bblayers_conf()Markus Lehtonen2015-09-291-0/+1
| | | | | | | | | | | | | | Prevent edit_bblayers_conf() from adding layer(s) multiple times. This happened when BBLAYERS variable was "listed" multiple times in bblayer.conf - i.e. the configuration was split into multiple separate assignments. [YOCTO #8316] (Bitbake rev: 5e423237f9f4ff7e7e03bf066b0142ba4bd82219) Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: Revert "bitbake: toaster: don't re-create Target objects"Michael Wood2015-09-291-1/+16
| | | | | | | | | | | | | This delete followed up the foreign keys and deleted things that were not expected to be deleted. This reverts commit 08000eb27eb8413686fb2c8daf14d234a8bff83a. (Bitbake rev: 46b119eb62a5a612fe4c0847862d34f408e556f7) Signed-off-by: Michael Wood <michael.g.wood@intel.com> Signed-off-by: brian avery <avery.brian@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2025-08-18 08:12:24 +0000