Commit message (Collapse)AuthorAgeFilesLines
* runqueue: Ensure setscene tasks that aren't covered get builtHEADmaster-nextmasterRichard Purdie13 days1-2/+4
| | | | | | | | | | | | | | | | | | Running "bitbake gconf-native -c cleansstate; bitbake core-image-sato:do_populate_sdk" results in a build where it fails to find gconf-native and fails to build it, merrily trying to build the SDK without gconf being present. The issue is the missing setscene tasks are effectively ignored as the later code in runqueue thinks that since other sstate tasks are present, these 'cover' the missing one. In reality we need to call BB_SETSCENE_DEPVALID to make that decision. To do that we need a "reduced" setscene dependency graph which we don't have in main task graph context. Since that was already done in setscene, we should just assume anything in the non-covered list needs to be built. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cooker/runqueue: Turn universe warnings into verbnotesRichard Purdie13 days2-2/+2
| | | | | | | If the user puts universe on the commandline, they don't really want warnings so use the new verbnote level instead. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* msg: Add explicit verbnote log levelRichard Purdie13 days2-0/+19
| | | | | | | | It has become apparant we need a log level which reaches the console but isn't a warning/error. Add "verbnote" as a way of doing this, behaves as a note but with a higher priority. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* server/process: Various server startup logging fixesRichard Purdie2018-09-043-13/+22
| | | | | | | | | | | | | | | | | | | | | | | There were various problems in the server startup loggin: a) stdout/stderr were not being flushed before forking which could potentially duplicate output b) there were separate buffers for stdout/stderr leading to confusing logs where the entries could be reordered. This was particularly confusing due to the separator the logs use to idendify new messages c) an fd wasn't being closed during server startup meaning if the server failed to start, the closed fd wasn't detected as it was held open by the other reference d) If the pipe was detected as being closed, the code incorrectly retried server startup e) The event code would remap stdout/stderr without flushing them, leading to lose log messages Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cooker.py: Fix incorrect bb files matched warningMark Hatle2018-09-043-1/+88
| | | | | | | | | | | | | | | | | | In the case of a sublayer of an existing layer, where the sublayer and main layer share a path, the system may not match the paths properly resulting in: No bb files matched BBFILE_PATTERN_sublayer '^/path/main/sublayer' because it has already matched the main layer. Fix this issue by sorting the collection items based on the pattern, using longest to shortest. Obviously regex wildcards could still be an issue but these are typically not used, so this simply fix should work in the existing cases. Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* tests/fetch: Update gnome.org urls after upstream changesRichard Purdie2018-08-281-2/+2
| | | | Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* fetcher: Fixed remote removal not throwing exception.Paulo Neves2018-08-281-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this fix it is assumed that the removal of the remote can only fail because there is not remote to remove. This is a false assumption. Example error which would be ignored: git -c core.fsyncobjectfiles=0 remote rm origin failed with exit code 1, output: Note: A branch outside the refs/remotes/ hierarchy was not removed; to delete it, use: git branch -d master error: could not lock config file config error: Could not remove config section 'remote.origin' Due to the masking of this error a stranger error will be presented to the user, because this time we do not mask the exception: git -c core.fsyncobjectfiles=0 remote add --mirror=fetch origin https://github.com/ptsneves/tl-wn722.git failed with exit code 128, output: fatal: remote origin already exists. The most likely reason that the remote cannot be removed nor modified is that the DL_DIR/git2 does not have permissions compatible with the user running bitbake. This commit fixes: https://bugzilla.yoctoproject.org/show_bug.cgi?id=12728 Signed-off-by: Paulo Neves <ptsneves@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* toaster: enable project import and merged Toaster settingsDavid Reyna2018-08-284-42/+48
| | | | | | | | | | | | | | | | Enable the ability to select an existing build directory into Toaster. This opens to the user the backend features of 12823, for command line user compatibility. Enable the ability to select saving Toaster settings in the regular "bblayers.conf" and "local.conf" instead of the default "toaster_bblayers.conf" and "toaster.conf". This opens to the user the backend features of 12821, for command line user compatibility. [YOCTO #12902] Signed-off-by: David Reyna <David.Reyna@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* toaster/layerdetails.js: don't hide local layer infoAwais Belal2018-08-281-1/+2
| | | | | | | | | | | | | | | The local layer info (provided through custom fixtures) should not be hidden. It is better to handle it in the same manner as an imported layer, otherwise the layer path and dependency info is not shown. The layer editing fields are handled in the html side of things appropriately so this does not harm that implementation. [YOCTO #12891] Signed-off-by: Awais Belal <awais_belal@mentor.com> Signed-off-by: David Reyna <David.Reyna@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* toaster/models.py: allow local paths for custom recipe's baseAwais Belal2018-08-281-0/+7
| | | | | | | | | | | | | In a case where the layer source is local only and the recipe is not yet built, we can search for the path with layer's local_source_dir, and if available that should be used rather than just skipping the scenario. [YOCTO #12891] Signed-off-by: Awais Belal <awais_belal@mentor.com> Signed-off-by: David Reyna <David.Reyna@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* toaster/checksettings: allow CUSTOM_XML_ONLY setting through envAwais Belal2018-08-281-1/+2
| | | | | | | | | | | | | This change allows the CUSTOM_XML_ONLY toaster setting to be provided through the environment so the user can do this without mingling with the settings.xml, for scenarios where modifying settings.xml is not achievable. [YOCTO #12891] Signed-off-by: Awais Belal <awais_belal@mentor.com> Signed-off-by: David Reyna <David.Reyna@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* toastergui/newproject.html: fix release divsAwais Belal2018-08-281-2/+2
| | | | | | | | | | | | | | | The release drop down divs are not being closed appropriately, which showed adverse reactions on the UI that aligned the "Create project" button with the left edge of the screen without any margins. This fixes these divs which in turn aligns the button appropriately. [YOCTO #12891] Signed-off-by: Awais Belal <awais_belal@mentor.com> Signed-off-by: David Reyna <David.Reyna@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* toaster/widgets.py: avoid divide by zero issuesAwais Belal2018-08-281-7/+12
| | | | | | | | | | | | | | | There can be cases where the variables being used to divide in build percentage expressions can be zero. For example, a setup consisting of only local repos will have repos_to_clone=0 and will generate a divide by zero scenario. Fix this by checking the divisor in such cases. [YOCTO #12891] Signed-off-by: Awais Belal <awais_belal@mentor.com> Signed-off-by: David Reyna <David.Reyna@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* toaster: allow TOASTER_DIR to be overridden from cmdlineAwais Belal2018-08-281-2/+7
| | | | | | | | | | | | | | | | | TOASTER_DIR is used for higher level toaster artifacts such the SQL DB and creating toaster internal build directories for projects. Prior to this change it was evaluated as `dirname $BUILDDIR` and user had no control over it. This change allows to override this variable from the command line for more flexibility. The variable defaults to its original setting if the optional argument is not passed. [YOCTO #12891] Signed-off-by: Awais Belal <awais_belal@mentor.com> Signed-off-by: David Reyna <David.Reyna@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* toaster: use a more flexible way to find bitbakeAwais Belal2018-08-281-1/+12
| | | | | | | | | | | | | | | | | | | | | | | The current mechanism for finding the bitbake binary assumes a directory structure which is identical to poky, where oe-core's meta and bitbake directories are at the same level. There can be a case where bitbake is used from elsewhere and in such cases the above mentioned assumption fails to hold, whereas this is totally allowed by the oe-init-build-env script which can take bitbakedir as an argument. The better approach is to allow bitbake to be derived from PATH, while keeping the older mechanism in place so it can be removed after tests are done in various environments. This makes more sense as toaster has also been launched from the same bitbake instance that is the one in PATH. [YOCTO #12891] Signed-off-by: Awais Belal <awais_belal@mentor.com> Signed-off-by: David Reyna <David.Reyna@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* toaster: allow pokydirname to be evaluated when all layers are localAwais Belal2018-08-281-3/+15
| | | | | | | | | | | | | | | | | | Toaster depends on pokydirname for identifying the location of the oe-init-build-env script (and there might be other purposes in the future). The problem with current approach is that it only checks/sets the variable with git based repos, whereas toaster provides mechanisms to allow having layers that are all locally available. The evaluation of the variable fails in such scenarios, so use a more flexible mechanism in this case and try to locate poky in the local layers as well, if not already set. [YOCTO #12891] Signed-off-by: Awais Belal <awais.belal@mentor.com> Signed-off-by: David Reyna <David.Reyna@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* parse/ast: ensure saved event handlers really do get restoredPaul Eggleton2018-08-241-18/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In finalize() we save event handlers, register the ones relevant to the recipe being finalised, trigger events, and then restore the handlers so that one recipe's custom handlers (actually implemented within a class inherited by the recipe) do not affect other recipes. However, if an exception occurs during parsing, the saved handlers were not being restored. Use a try...finally block to ensure that the handlers are always restored. This issue became apparent since in OpenEmbedded-Core we have recently introduced a find_intercepts() handler for the bb.event.RecipePreFinalise event in image-postinst-intercepts.bbclass that images and old-style SDK recipes will end up inheriting. So far it doesn't seem that the the error has manifested itself in normal builds, but when parsing OE-Core recipes in the OE layer index it has: core-image-rt-* image recipes were parsed which in the default configuration raise SkipRecipe. The next non-image recipe that is parsed will trigger a real exception, because the find_intercepts() handler is still registered and gets fired, but in the context of the new recipe the POSTINST_INTERCEPTS_PATHS variable is not set, and the code in find_intercepts() is written with the reasonable assumption that that isn't possible given that the class itself sets a default, and thus it fails. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: Bump version 1.39.0 -> 1.39.1Richard Purdie2018-08-232-2/+2
| | | | Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* daemonize: Flush stdio on exitJoshua Watt2018-08-211-2/+7
| | | | | | | | | | | | | In spite of a comment suggesting otherwise, os._exit() does not flush buffered output from file descriptors before exiting the process like os.exit() does. This means that any un-flushed output is lost in the daemon process, in particular the traceback from any thrown exceptions, making debugging exceptions in the daemon quite difficult. The solution is to flush stdout and stderr before exiting. Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* toaster: Fix comparison in recipe templateKarsten Strand2018-08-211-1/+1
| | | | | | | | | Use == instead of = when comparing task outcome to OUTCOME_FAILED. Prior to this fix the recipe template would cause a TemplateSyntaxError exception. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Toaster: Implement the project-specific feature and releated enhancements ↵David Reyna2018-08-2029-55/+1900
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and defects. Here is the primary driving enhancement: * Bug 12785 - Support Project Specific configuration for external tools (e.g. ISS, Eclipse) - Isolated project-specific configuration page (full Toaster context hidden) - Support for new project, reconfigure existing project, and import existing command line project - Ability to define variables (e.g. image recipe) and pass them back to external GUI - Ability to execute the cloning phase, so that external GUI receive a buildable project - Ability to call back to the external GUI when updates are completed and ready - Compatibility of above projects with the normal full Toaster interface - Ability to pass to a 'complete' or 'cancel' web page so that the external GUI can immediately stop that Toaster instance, and not leave dangling servers nor edit sessions open Here are the supporting enhancements, where at least the back end is implemented: * Bug 12821 - Make Toaster conf changes compatible with command line usage * Bug 12822 - Support importing user changes to conf files into Toaster * Bug 12823 - Support importing user build directories into Toaster * Bug 12824 - Scan imported layers for content so that they are immediately available * Bug 12825 - show layer clone item in progress bar Here are defects fixed: * Bug 12817 - builddelete.py requires explicit 'add_arguments' * Bug 12818 - Remove orphaned imported layers when project is deleted * Bug 12826 - fix imported layer management * Bug 12819 - build using selected bitbake env, not Toaster's env * Bug 12820 - Toaster randomizes the layer order in toaster_bblayers.conf [YOCTO #12785] Signed-off-by: David Reyna <David.Reyna@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bb/utils.py: add break_hardlinks helperRasmus Villemoes2018-08-161-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | bb.utils.copyfile is called in a few places with identical src and dst in order to create an st_nlinks==1 version of the file. That that even works relies on an implementation detail of copyfile (namely, that it creates a temporary file and then does a rename). Moreover, it's a waste of time if the file already has st_nlinks==1. So create a helper that optimizes away the copy in the st_nlinks==1 case. Of course, this helper relies on the same implementation detail, but that's now contained within bb.utils itself. To test that we do at least sometimes hit the no-copy path, I tested locally with if sstat[stat.ST_NLINK] == 1: + bb.note("Woohoo, 2*%d bytes I/O avoided" % sstat[stat.ST_SIZE]) return True (and the obvious places in oe-core patched), and the do_package log files are indeed filled with woohoo notes. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqueue: Move decision if a task can be started to one common placeAndreas Müller2018-08-151-4/+8
| | | | | Signed-off-by: Andreas Müller <schnitzeltony@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* utils/md5_file: don't iterate line-by-lineRoss Burton2018-08-151-4/+9
| | | | | | | | | | | | | Opening a file in binary mode and iterating it seems like the simple solution but will still break on newlines, which for binary files isn't really useful as the size of the chunks could be huge or tiny. Instead, let's be a bit more clever: we'll be MD5ing lots of files, but we don't want to fill up memory: use mmap() to open the file and read the file in 8k blocks. Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* checksum: sanity check path when recursively checksummingRoss Burton2018-08-141-0/+2
| | | | | | | | In case something goes tragically wrong, catch a request to checksum / and refuse. Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* event.py: fix typoKai Kang2018-08-141-1/+1
| | | | | Signed-off-by: Kai Kang <kai.kang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqueue: Allow the hash validate function to have an idea of build completionRichard Purdie2018-08-071-0/+5
| | | | | | | | | | | | There is an oversight in the current hash validation API in that the function can't know how many setscene tasks already completed. Rather than trying to add additional parameters to the function, causing incompatibilities, store the value in the datastore. This is useful to allow build status reporting to the user for figures on sstate reusage and build completion. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* toaster/orm/management/commands/lsupdates.py: Use new layerindexlib moduleMark Hatle2018-08-011-131/+97
| | | | | | | | | | | | Change lsupdates.py to use the new layerindexlib module to load the data from the public layer index. It still does all of the manual parsing. This is intended to be a stop gap until the toaster can use the module itself to manage the data. Everything else is functionally equivalent to the prior version. Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake-layers: disable parsing for layerindex commandsMark Hatle2018-08-011-2/+2
| | | | | | | | | These don't need to access recipe information, so let's not waste the user's time parsing all recipes. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bblayers/layerindex.py: Switch to use the new layerindexlib classMark Hatle2018-08-011-185/+119
| | | | | | | | | | | | | | | | | | | Display changes: The output will now include references to the layers that the user already has on their system. It does this by querying the cooker derived index. The code that enables this behavior is labeled as 'TODO' currently. As part of the work we need to make a final determination if this is the desired output. Also changed the default branch to no longer define itself as 'master'. When the user does NOT set a branch, the default is now the 'LAYERSERIES_CORENAMES', and if that doesn't exist 'master'. This is subtly different in behavior, but more consistent with user expectations. Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* layerindexlib: Initial layer index processing module implementationMark Hatle2018-08-0117-1/+2866
| | | | | | | | | | | | | | | | | | | | The layer index module is expected to be used by various parts of the system in order to access a layerindex-web (such as layers.openembedded.org) and perform basic processing on the information, such as dependency scanning. Along with the layerindex implementation are associated tests. The tests properly honor BB_SKIP_NETTESTS='yes' to prevent test failures. Tests Implemented: - Branch, LayerItem, LayerBranch, LayerDependency, Recipe, Machine and Distro objects - LayerIndex setup using the layers.openembedded.org restapi - LayerIndex storing and retrieving from a file - LayerIndex verify dependency resolution ordering - LayerIndex setup using simulated cooker data Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bblayers/layerindex.py: Fix addition of layersMark Hatle2018-08-011-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | When a layer is added it needs to be in a list, otherwise the system will error such as: Specified layer directory / doesn't contain a conf/layer.conf file Additionally, instead of calling the add layer function over and over, it is better to add all of the new content in one command. Otherwise the order is important as the system now checks if the layer can be added. For instance, trying to add meta-python: Layer Required by Git repository Subdirectory =================================================================================================================== meta-python - git://git.openembedded.org/meta-openembedded meta-python meta-oe meta-python git://git.openembedded.org/meta-openembedded meta-oe openembedded-core meta-python git://git.openembedded.org/openembedded-core meta Adding layer "meta-python" (.../oe-core/meta-openembedded/meta-python) to conf/bblayers.conf ERROR: Layer 'meta-python' depends on layer 'openembedded-layer', but this layer is not enabled in your configuration The system would try to add meta-python before the dependent meta-oe. Adding them both at the same time resolves this issue. Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bblayers: Don't parse all recipes when calling add-layerRichard Purdie2018-08-011-1/+1
| | | | | | | | | When adding multiple layers in a chain of commands, reparsing all recipes each time can be painfully slow. Instead just parse the base configuration which gives some confidence things worked out correctly without as much overhead. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: Add support for multiconfig dependenciesAlejandro Enedino Hernandez Samaniego2018-08-015-8/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the capability for tasks from different multiconfigs to depend on one another. These dependencies can be enabled using the following format: task[mcdepends] = "multiconfig:FROM-MC:TO-MC:PN:task-to-depend-on" For the sake of simplicity consider the following example: Assuming we have set up multiconfig builds, one for qemux86 and one for qemuarm, named x86 and arm respectively. Adding the following line to an image recipe (core-image-sato): do_image[mcdepends] = "multiconfig:x86:arm:core-image-minimal:do_rootfs" Would state that core-image-sato:do_image from x86 will depend on core-image-minimal:do_rootfs from arm so it can be executed. This patch makes modifications to: - cooker: To glue both multiconfigs in one place and make sure the dependencies can be provided. - taskdata: To parse and add a new kind of dependency (mcdepends) to the taskdata object. - runqueue: To differentiate tasks from different multiconfigs, add the specified dependencies to the corresponding tasks, and create a working runqueue that contains tasks from both multiconfigs. - siggen: To avoid looking for tasks from different multiconfigs on objects where they dont belong. The taskdata objects are still not aware of the concept of multiconfig, so each object doesnt know which multiconfig its building, hence why the mcdepends are added to all taskdata objects equally (we really dont expect many of these), but the actual dependencies are added only to the required tasks by the runqueue. Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* codeparser: Track oe.utils.conditional usageMartin Jansa2018-07-262-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | * base_conditional was already removed from oe-core: http://git.openembedded.org/openembedded-core/commit/?id=0391fcad9103abca0796a068f957d0df63ab4776 after the usage was migrated to oe.utils.conditional: http://git.openembedded.org/openembedded-core/commit/?id=c97acbd034532895ce57c6717ed1b3ccc7900b0d so we can handle just ".conditional" version * add 1st parameter to variable dependencies, that way when you use FOO = "${@oe.utils.conditional('VAR', 'VALUE', 'true', 'false')" FOO variable will have dependency on VAR variable and you don't need to add FOO[vardeps] += "VAR" manually every time you use oe.utils.conditional * this is similar to contains tracking from: https://bugzilla.yoctoproject.org/show_bug.cgi?id=3890 http://git.openembedded.org/bitbake/commit/?id=ed2d0a22a80299de0cfd377999950cf4b26c512e http://git.openembedded.org/bitbake/commit/?id=0b9d117631ce909312d53b93289e61defc6be01c but conditional is simpler, we don't need to handle the first parameter as a set Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* utils: add optional callback to edit_bblayers_conf()Paul Eggleton2018-07-261-1/+14
| | | | | | | | | | Add a callback that lets you modify or remove items in addition to the current scheme where you can only add or remove. This enables you to for example replace a layer with a temporary copy (which is what we will use this for first in OE's oe-selftest). Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* server/process: Always place the server logfile in the build directoryRichard Purdie2018-07-251-2/+3
| | | | | | | | Currently the bitbake-cookerdaemon.log is placed into cwd. This seems like a bad idea, we can place it in the build directory alongside the lockfile that represents the server instead. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqueue: Stop on first unsatisfied dependencyJoshua Watt2018-07-091-3/+4
| | | | | Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqueue: Remove unused variableJoshua Watt2018-07-091-2/+0
| | | | | Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* siggen: Delete trailing whitespaceJoshua Watt2018-07-091-2/+2
| | | | | Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqueue: Remove trailing whitespaceJoshua Watt2018-07-091-1/+1
| | | | | Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqueue.py: Fix a virtual class extension stamps issueMing Liu2018-07-021-1/+1
| | | | | | | | | | | | | | | | | | | | The file_name parameter passed to bb.parse.siggen.invalidate_task should be a virtual file name instead of a real file name, or else you will encounter a following error, for instance, when you run: $ bitbake nativesdk-lzip -c unpack -f the error arise: | ERROR: An uncaught exception occurred in runqueue | if file_name: | > taintfn = d.stamp[file_name] + '.' + task + '.taint' | else: | KeyError: 'virtual:nativesdk:/opt/poky/meta/recipes-extended/lzip/lzip_1.19.bb' when multilib builds are used on OE. Signed-off-by: Ming Liu <liu.ming50@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* fetch2: Use correct check in parameter handling in uri_replace()Nikolai Merinov2018-06-192-2/+4
| | | | | | | | If uri_find contain parameters then original URI parameters should be checked against parameters from uri_find instead of parameters from uri_replace. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake-user-manual: Added "number_threads" varflagScott Rifenbark2018-06-191-0/+32
| | | | | | | | | | You can now limit on a task-specific basis the number of threads a task will use. This is useful for machines that have high numbers of cores and need to be rate-limited due to various resource constraints. Signed-off-by: Scott Rifenbark <srifenbark@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqueue.py: Initial implementation of per task process limitsMark Hatle2018-06-151-0/+21
| | | | | | | | | | | | | | | | | On high core machines, in do_fetch, it is possible to DDoS your own machine. A method to limit any arbitrary task type to a certain number of simultaneous threads is needed. (Similar to how BB_NUMBER_THREADS works in the general case.) The format of this new limitation is: do_fetch[number_threads] = "2" This should be set globally. If it is set in individual recipes it could result in unpredictable behavior. Note: a value for number_threads > BB_NUMBER_THREADS will have no effect. Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqueue.py: Minor cleanup for RunQueueStats and usersMark Hatle2018-06-151-9/+9
| | | | | | | | | | | | | | | The RunQueueStats:taskCompleted and RunQueueStats:taskSkipped can take multiple arguments. However, nowehere in bitbake are multiple arguments used. Change this to match the behavior of the other APIs where it needs to be called once for each task. Additionally, these two functions were usually called in tandem, however in the wrong order. It really doesn't matter as there is no specific preemption point between the calls. But the taskSkipped should be called first to increment the 'active' count, and then taskCompleted called to decrement it. Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* fetch2: unify the way fetchers determine DL_DIR and FETCHCMDAndre McCurdy2018-06-158-21/+23
| | | | | | | | | | | | | Currently there is quite some variation between the fetchers in terms of how they determine the subdirectory within DL_DIR and the base fetch command to run. Some rely on variables being set externally (e.g. from bitbake.conf in oe-core), some respect these external variables but provide fallback defaults and some use only hardcoded internal values. Try to unify the approach used across the various fetchers. Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* fetch/gitsm: avoid live submodule fetching during unpack()Matt Hoosier2018-06-061-8/+75
| | | | | | | | | | | | | | | | Although the submodules' histories have been fetched during the do_fetch() phase, the mechanics used to clone the workdir copy of the repo haven't been transferring the actual .git/modules directory from the repo fetched into downloads/ during the fetch task. Fix that, and for good measure also explicitly tell Git to avoid hitting the network during do_unpack() of the submodules. [YOCTO #12739] Signed-off-by: Matt Hoosier <matt.hoosier@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: Update version to post release 1.39Richard Purdie2018-06-062-2/+2
| | | | Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* fetch2: fix import error for Python 3.6.5Tzu Hsiang Lin2018-05-292-3/+1
| | | | | | | | | | When running bitbake command with Python 3.6.5 always result in import error causing by the change of distutils module. This patch replaces the method to search executable in PATH by "/usr/bin/env <command>". Signed-off-by: Tzu Hsiang Lin <t9360341@ntut.org.tw> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>