summaryrefslogtreecommitdiffstats
path: root/bitbake/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* bitbake: toaster: Order column in Tasks selectableAwais Belal2017-09-051-0/+3
| | | | | | | | | | | | | | | | | | | The build page provides tables related to performance that cover build time, CPU time and disk IO. The "Edit columns" drop down does not allow selection of the Order column and makes it hidden as well which is not accurate from user interaction point of view. This patch enables the hideable property for the Order column so it is hidden by default but the user can enable it through the drop down if need be. [YOCTO #11040] (Bitbake rev: 1f1cc1edb21aeec684ef7323554794b33d84d414) 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>
* bitbake: toaster: display error when the fstype select is emptyDavid Reyna2017-09-051-0/+3
| | | | | | | | | | | | | | There must be at least one FSTYPE selected in the Toaster bitbake variable editor page. When the user deselects all the "Save" button gets disabled, but the error message is missing. [YOCTO #8126] (Bitbake rev: 193577655b7491126ca5fa91fa76d79329e900c2) Signed-off-by: David Reyna <David.Reyna@windriver.com> Signed-off-by: David Reyna <David.Reyna@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Ensure parseConfiguration clears parsecache_validRichard Purdie2017-09-021-0/+2
| | | | | | | | | | | | BB_SERVER_TIMEOUT=100 oe-selftest -r bblayers was failing and highlighted that since parseConfiguation clears data structures, it needs to also clear parsecache_valid as it no longer contains correct data. (Bitbake rev: 7234f33a7eb38ad51a8345f6689bc26e29f29f92) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata/taskdata/runqueue: Drop remaining tryaltconfigs code and ↵Richard Purdie2017-09-024-14/+3
| | | | | | | | | | | | | commandline option I can't actually see how this was working, nothing connected the commandline option to the data in TaskData(). Drop the remaining pieces of this option, it was a relic from a decade ago and we want deterministic builds, not random tries until something might work. (Bitbake rev: 767c7ba8fc76ec667ac1567de1c971c3575f2ecd) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Add reset to SignatureGeneratorCaio Marcelo de Oliveira Filho2017-08-311-0/+3
| | | | | | | | | | | Fix failure after commit "cooker/siggen: Reset siggen when reparsing" (e4c6ca9440f63761560b49bbe12654441f54687e) when executing without specifying a BB_SIGNATURE_HANDLER. (Bitbake rev: 2a78c2d09aea0323632bbc927f370f1d3c9c249e) Signed-off-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Ensure buildFile doesn't have lasting side effectsRichard Purdie2017-08-311-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | BB_SERVER_TIMEOUT=100 oe-selftest -r devtool.DevtoolTests.test_devtool_build_image fails, the reason is that internally, the limited_deps flag is set in the bitbake server and then never cleared. This causes the sysroots to be setup incorrectly (as per the limited dependency case) and builds break. There is also potential for corruption of recipecaches. Add shutdown/cleanup code to ensure these effects don't 'stick'. This bug is particularly nasty as you can destroy TMPDIR with large sysroots in build work directories which are prone to break. Also ensure mtime cache is cleared (to match buildTargets) and that no lasting changes are made to siggen either which ensures: BB_SERVER_TIMEOUT=100 oe-selftest -r devtool.DevtoolTests.test_devtool_upgrade_git devtool.DevtoolTests.test_devtool_virtual_kernel_modify works. (Bitbake rev: 0a7ee8c8378bba9877c260b1aee782878f1935b4) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2/npm: add noverify parameter to skip lockdown/shrinkwrapPaul Eggleton2017-08-311-20/+21
| | | | | | | | | | | | | | | | When fetching source for the first time within scripts such as OpenEmbedded's recipetool, we don't want to be showing warnings about NPM_SHRINKWRAP or NPM_LOCKDOWN not being set since there's no way we could have set them in advance. Previously we were using ud.ignore_checksums to suppress these but since we are now using a more standard task-based path to fetch the source, we need to disable these through the metadata. Look for a "noverify" parameter set on the npm URL and skip the checks if it is set to "1". (Bitbake rev: 8c4b35d1e4d31bae9fddd129d5ba230acb72c3bb) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: ensure we can run buildFileInternal() after cache is populatedPaul Eggleton2017-08-311-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | If you run some other operations that result in the cache being populated, and then call buildFileInternal(), then you can end up in a situation where the cache already contains information about the recipe. For example in OE this can now happen when you use devtool upgrade. Normally this doesn't cause any problems, unless you have a non-absolute path in BBLAYERS - in buildFileInternal() we are calling matchfile() which will convert the filename to absolute, but later when taskdata goes to find the providers of the recipe it finds the non-absolute path, sets up the task information using this and then the runqueue can't find any tasks matching the absolute path. To fix this, back out the optimisation I did earlier in bitbake rev ba53e067a2d448dd63b4ca252557ce98aa8e6321 to avoid calling parseConfiguration() again, which is unfortunate but does result in the cached information being that causes the problem being cleared out. This fixes "Task do_unpack does not exist for target ..." running devtool upgrade within intel-iot-refkit. (Bitbake rev: f120355eaec4571ba6d60fc5f7ae9e1f31d846d1) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: ensure variable history tracking works when parsing a recipePaul Eggleton2017-08-311-11/+18
| | | | | | | | | | | | | | | | | | If you set tracking=True when creating the tinfoil object, that ensures history is collected for the main datastore, but at the end of parsing the configuration, history tracking gets turned off to save time with the result that we don't collect history for any recipes we parse. Enable tracking when we parse a recipe (and disable it afterwards if we enabled it) in order to fix this. This fixes functionality in OE's devtool that relies upon variable history (such as devtool upgrade updating PV when it's set within a recipe). (Bitbake rev: cc8b4c81bb589fb70774a0151f87a8d277f40f06) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: ensure log lines get printed when tasks failPaul Eggleton2017-08-312-23/+34
| | | | | | | | | | | | | | If a task fails during build_targets(), we need to print out the log lines as knotty does or the user will be missing information about the failure. (This should get some deeper refactoring, but now isn't the time for that.) (Bitbake rev: 24879df071d4803db3d39ae1d5cad852daa92f28) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: fix log message doubling when config_only=FalsePaul Eggleton2017-08-311-0/+11
| | | | | | | | | | | | | | With config_only=False we launch the UI and it sets up a logger, whereas when config_only=True we don't, with the result that with True we are seeing log messages from both our logger and the one set up by the UI. Suppress our loggers with config_only=True to avoid this. Fixes [YOCTO #11275] (again). (Bitbake rev: b5e3b28b7c982dd8a3991d727f25710dbf58bb80) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: prserv/serv: Gracefully handle the PR server exiting quicklyRichard Purdie2017-08-311-1/+5
| | | | | | | | | If the server exits quickly its PID may no longer exist. Handle this gracefully. (Bitbake rev: c1b00a9265fa4146b8db8b7d03a51bf2bfcf9f51) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: prserv/serv: Rename self.quit -> self.quitflagRichard Purdie2017-08-311-6/+6
| | | | | | | | | self has a quit function and a variable. Separate this to two different things as the current setup is prone to breakage. (Bitbake rev: ba7e3c73d8f4d2bd1d7434b97c326e7ab935231a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: prserv/serv: Send sentinel to stop handler threadRichard Purdie2017-08-311-1/+4
| | | | | | | | | Shutdown from SIGTERM currently has to wait for the handler thread to timeout. Add a sentinel value which triggers it to loop and allows for a quick exit. (Bitbake rev: a7591ef34ce70ff1d7aa9362d7473e6f16fbd10f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: ui/knotty: Send updateConfig earlyRichard Purdie2017-08-311-1/+3
| | | | | | | | | | | | | | | | | | If for example you run: bitbake -r somefile.inc rm somefile.inc bitbake -e bitbake will crash with an error about not being able to find somefile.inc. This is because it tries to reparse the base config for the early getVariable requests before it sees the updated missing -r option. Send the updateConfig command earlier to avoid this. (Bitbake rev: a38164620ebdc770690c5f39ff9ed69d3f82719e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: Avoid tracebacks from early reset() callsRichard Purdie2017-08-311-0/+3
| | | | | | | | | cooker.reset() can be called before we've actually setup the datastore. Gracefully handle this case instead of the current traceback+exit. (Bitbake rev: 8fd30ca6d271c125a8ea03ef0c5d7ab176900701) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Allow changes in PRSERV_HOST to be responded toRichard Purdie2017-08-311-8/+11
| | | | | | | | | | | | | | When we reload the configuration, PRSERV_HOST can change. Therefore restart the PR Server depending on the new configuration at reparse. Note that the server has to be started from the right process, it can't be in the UI which shuts down as that shutdown triggers a shutdown of its children and the PR Server shuts down too. This is why we need pre_serve() which ensures its executed in the right context. (Bitbake rev: 971272e84f4efe7ebd0037e164ba54f013a2a34e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: prserv/serv: Shut down any existing server before restartingRichard Purdie2017-08-311-0/+3
| | | | | | | | | This allows for cleaner code in cooker as any existing server is dealt with before a new one is started. (Bitbake rev: b8616931bc0e523a3a3bb23b4f623f8b6e71d690) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Change to consistent prefile/postfile handlingRichard Purdie2017-08-313-21/+10
| | | | | | | | | | | | | | Currently the original prefile and postfile passed when starting bitbake server are 'sticky'. With the new memory resident model this doesn't make sense as the server the system is started with isn't special. This patch changes the code so the prefile/postfile are used if specified on the commandline and not used otherwise. This makes the behaviour much more predictable and expected and as an added bonus simplifies the code. (Bitbake rev: 638d366234fad78f283d3a13a12b07cb0ccbe914) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Handle datastore tracking for showEnvironment server side onlyRichard Purdie2017-08-312-7/+11
| | | | | | | | | | The current passing of "tracking" backwards and forwards, client to server is ugly and complex and error prone. Instead, set this during showEnvironment commands triggering a reset there if/as required. (Bitbake rev: 9dc7f384db0479569ff93a76a623d5395fecaf47) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: prserv/cooker: Drop unused paramRichard Purdie2017-08-312-2/+2
| | | | | | | | Drop pointless unused function parameter. (Bitbake rev: 8104b33656de0b619943bd7a9884eb650ccafbf4) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: command: Fix some bugs identified by BB_SERVER_TIMEOUTRichard Purdie2017-08-311-1/+2
| | | | | | | | | | | | | | | | | | | | The 'needconfig' flag was meant to be the default as most commands do need it and the "False" cases were the exception. The code was written backwards with a default False value. Invert this to match the intent, resulting in the config being reparsed if metadata has changed. Also ensure the second level configuration is parsed for the getLayerPriorities command as otherwise it can return stale info. With these changes: BB_SERVER_TIMEOUT=100 oe-selftest -r bblayers.BitbakeLayers.test_bitbakelayers_add_remove passes instead of fails. (Bitbake rev: af3c8928a69f204d5ced02c947485990ac04a776) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: main: Attempt to gain bitbake.lock rather than just waitingRichard Purdie2017-08-241-1/+9
| | | | | | | | | Rather than just waiting for 5s, try and get the lockfile. If we gain the lock, we know we're ready to retry and can skip any remaining timeout. (Bitbake rev: 8a60106c6f7d586c793b965c5e9460b6016fab15) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: process: Clean up connection retry logicRichard Purdie2017-08-242-7/+14
| | | | | | | | | | | | | | | | | | Its possible for a connection to connect to the server as its shutting down but before its removed the socket file. This patch: a) Removes the socket file earlier to avoid connections. b) Handles EOFError in initial connections gracefully. These occur if the socket is closed during the server shutdown. c) Ensure duplicate events aren't shown on the console. This makes debugging these issues very very confusing. With these changes the backtrace that was concerning users is hidden and the server works as expected with a reconnect when it catches it in a bad state. (Bitbake rev: f45196cf84669723382730944dddc7eaf50826f2) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2: don't mandate path element in encodeurl()Paul Eggleton2017-08-231-6/+5
| | | | | | | | | | | | | URLs do not have to have a path; currently our npm URLs don't, so encodeurl() needs to handle if the path element isn't specified. This fixes errors using OpenEmbedded's devtool add / recipetool create on an npm URL after OE-Core revision ecca596b75cfda2f798a0bdde75f4f774e23a95b that uses decodeurl() and encodeurl() to change URL parameter values. (Bitbake rev: d5cab2dbf5682d2fd08e58316a3bf39a10f63df2) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: ui: Sort 'Dependent tasks' in taskexpJussi Kukkonen2017-08-231-1/+3
| | | | | | | | | | The underlying model is already sorted for use in the other view, add a sorting model for the 'Dependent Tasks' view. (Bitbake rev: 27ca94c33234f0ef9753f8285213dde2871a3fcf) Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: support custom Layer Index URL and fixture overrideDavid Reyna2017-08-232-2/+9
| | | | | | | | | | | | | | | | | | | | Toaster needs to allow the custom fixture file to specific an alternate Layer Index URL for users that host their own Layer Index Server via the 'CUSTOM_LAYERINDEX_SERVER' in 'custom.xml'. Toaster also needs to allow the ability to completely override the default fixture files, otherwise that content can leak into the custom environment (by default the custom fixture is an overlay that cannot remove existing values from the default fixture) via the 'CUSTOM_XML_ONLY' value in 'setting.xml'. [YOCTO #11938] (Bitbake rev: ac29d4a9078494544a2627d8b6b021096b49cb34) Signed-off-by: David Reyna <David.Reyna@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: Toaster: custom start and stop actionsDavid Reyna2017-08-231-0/+49
| | | | | | | | | | | | | | Toaster needs the ability to allow custom extensions to execute when Toaster is started and stopped. Toaster will look for a custom extension script in the fixtures directory and execute any applicable hooks. [YOCTO #11938] (Bitbake rev: 12a73f6914488029f2b9dd680e004fba7dde41af) Signed-off-by: David Reyna <David.Reyna@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: custom image updates and original creationDavid Reyna2017-08-232-38/+62
| | | | | | | | | | | | | | | | | | | | | When Toaster removes a package from a custom image, it must also always remove the advised reverse-dependent recipes. Similarly, when adding a package it must always add its advised the packages it depends on. This code must be un-indented so that it applies to all respective added or removed packages. Toaster normally waits until a new custom image is built before creating the custom layer and the recipe. However, an intermediate different build can fail because the recipe has already been added to the project, so the image's default recipe must be created when the image is created. [YOCTO #11915] (Bitbake rev: bcd68fd7231f166baff875fb88e4f9ce0d9bf91d) Signed-off-by: David Reyna <David.Reyna@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: process: Ensure we call select() to know which fds to readRichard Purdie2017-08-221-1/+1
| | | | | | | | | | | | | | | | | | | There is an interesting bug in the current code where a sync command is not seen until the current async command completes, by which time the UI may have shut down. The reason is that if there are idle commands, we may not end up sleeping in the select call at all, partiularly under heavy load like parsing. Fix this by calling select with a zero timeout so that we see active fds and know to read from them. This fixes various problems toaster was having with the recent server changes. [YOCTO #11898] (Bitbake rev: bbcce58e824b2793abf50efa52db158ae16e23e4) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: process: Increase server startup timeoutRichard Purdie2017-08-161-1/+1
| | | | | | | | | | We're seeing the server fail to start within 8s on heavily loaded autobuilders so increase this timeout to 30s which should be more than enough time. (Bitbake rev: 8d4c120ec46d6d7a54947c64d33e18cb60b60505) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: process: Improve client disconnectsRichard Purdie2017-08-161-15/+23
| | | | | | | | | | There have been cases where the server could loop indefinitely and incorrectly handle client disconnects. In the EOFError case, ensure a full disconnect happens in the alternative disconnect path to avoid this. (Bitbake rev: 5e267f14bb0155889615f567a920af4a37eb3c6b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Ignore common bitbake files for the parse cache invalidationRichard Purdie2017-08-131-0/+3
| | | | | | | | | | | | | | Writes to the cookerdaemon log and/or the lockfile were meaning the parser cache was always being invalidated and reparsed. This is unnecessary so spot accesses to these two common cases and ignore the files from a reparse perspective. This doesn't remove many sources of reparse but does improve several common cases. (Bitbake rev: 218e4b6418992588312b8ef5949b84ef43263d1a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Improve inotify overflow handlingRichard Purdie2017-08-132-1/+8
| | | | | | | | | | Add a proper function for clearing the mtime cache. Clean up the inotify event overflow case to err on the side of caution and clear any potentially now out of sync caches. (Bitbake rev: ec60459fe2ba16966544eebff43b061abb7ed3ba) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Ensure we handle inotify before running the next commandRichard Purdie2017-08-132-7/+12
| | | | | | | | | | | | | | The inotify watch events are handled "at idle" which could in theory mean a command could run before any preceeding inotify events have been processed. This leads to a theoretical race window where those events may have a signficicant effect on the command. Add a mechanism to allow us to ensure all pending events are processed before running commands. (Bitbake rev: bf76cd7e5881adf264b8ba64e27a5b6ca9df4fde) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Track directories searched for bbappend/bb filesRichard Purdie2017-08-131-3/+21
| | | | | | | | | | | | | | | | | Some of the directories searched by BBFILES are not currently being added to the inotify watch list. This can mean that added append files are not noticed leading to misleading metadata results when using BB_SERVER_TIMEOUT != 0. We use glob to expand the BBFILES references and without writing our own implentation, figuring out the directories it searches is hard. We use some horrible hacks here to intecept the listdir calls, I'm open to better ways to handle this but this does ensure we have the right watches set. (Bitbake rev: 4d508d35a224e3a25d2d59c8415ab7985964b14f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/process: Ensure we don't loop on client EOFErrorRichard Purdie2017-08-131-2/+2
| | | | | | | | | | | | | | The server currently crashes if we hit an EOFError due to controllersock still being in ready and the continue meaning ready isn't re-evaluated. Setting the value to False can mean the shutdown code doesn't handle the situation cleanly. Clear ready to avoid the crash/loop instead and handle any OSError whilst we're in here. (Bitbake rev: 2bc47e887c3b41417edaa89a8708c223fd2085de) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker/siggen: Reset siggen when reparsingRichard Purdie2017-08-132-0/+4
| | | | | | | | | | | | If we don't do this, we get basehash mismatch errors occurring from the reparse which would then set bitbake's error exit code. This for example would cause oe-selftest -r bbtests.BitbakeTests.test_bbappend_order to fail with a non-zero BB_SERVER_TIMEOUT. (Bitbake rev: e4c6ca9440f63761560b49bbe12654441f54687e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: main: Handle BB_SERVER_TIMEOUT = -1 for no server timeoutRobert Yang2017-08-092-3/+6
| | | | | | | | | Make BB_SERVER_TIMEOUT = -1 mean no unload forever. (Bitbake rev: 923d5567be6fd9969ca74c166f36817ec09305e3) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: process: Fix disconnect when BB_SERVER_TIMEOUTRobert Yang2017-08-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed: $ export BB_SERVER_TIMEOUT=10000 $ bitbake --server-only $ bitbake --status-only [snip] File "/buildarea/lyang1/poky/bitbake/lib/bb/server/process.py", line 472, in recvfds msg, ancdata, flags, addr = sock.recvmsg(1, socket.CMSG_LEN(bytes_size)) OSError: [Errno 9] Bad file descriptor And: $ export BB_SERVER_TIMEOUT=10000 $ bitbake --server-only -B localhost:-1 $ bitbake --status-only # Everything is fine in first run $ bitbake --status-only [snip] File "/buildarea/lyang1/poky/bitbake/lib/bb/server/process.py", line 472, in recvfds msg, ancdata, flags, addr = sock.recvmsg(1, socket.CMSG_LEN(bytes_size)) OSError: [Errno 9] Bad file descriptor This was because self.controllersock was not set to False, so it still ran sock.recvmsg() when sock was closed. And also need set command_channel to Flase, otherwise the self.command_channel.get() will always run when EOF, and cause infinite loop. (Bitbake rev: 7b739a38601b053d9bea4df2c0b44a952ab670c4) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: main: Remove unneeded float()Robert Yang2017-08-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | There is already a type=float, so the float() is not needed, which also makes the error clearer: $ export BB_SERVER_TIMEOUT=10000AA With float(): $ bitbake quilt-native [snip] ValueError: could not convert string to float: '10000AA' Without float(): $ bitbake quilt-native [snip] optparse.OptionValueError: option --idle-timeout: invalid floating-point value: '10000AA' The second one tells clearly where is wrong. (Bitbake rev: 7a4ea1e6a10f20d80009a78f4f0aebf8f90095fd) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: Revert "tinfoil: fix duplication of log messages"Paul Eggleton2017-08-092-4/+3
| | | | | | | | | | | | | | | | | In combination with the recent server reworking, this change actually prevents messages sent from tasks from being logged properly. This will of course give us the duplicated messages back, and I really hate to do that effectively a second time, but that's better than seeing no error at all in the case of a failure - we'll have to find the proper way of avoiding the duplication that doesn't result in some messages going missing. This reverts commit 8a5bae76f91f2411187c638a42fa3c762052cf11. (Bitbake rev: 645c8dd15762516ae5ab64a1df47fadb95d072d1) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: daemonize: Always print any remaning UI events at exit2.4_M2Richard Purdie2017-08-031-1/+1
| | | | | | | | | | | | | If there are events in the UI queue we want to print them regardless of whether we're handling an exception or something like SystemExit. This improves error messages for some other failure cases where currently no logging would get printed and leave the user confused as to what went wrong. (Bitbake rev: 76c4f2c20216719736766e8ae7d089ccd061b71b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Ensure all tasks are shown in task dependency treeRichard Purdie2017-08-031-3/+3
| | | | | | | | | | | | "bitbake -g m4-native -c do_unpack" doesn't list any dependencies in task-depends.dot. This is because no header describing the task was added unless a task has dependencies. Tweak the code to fix this. [YOCTO #10893] (Bitbake rev: e2fbe728769f09ef4178e2ef4d69a2f60ffe3ebb) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: daemonize: clean up codeRichard Purdie2017-07-311-134/+14
| | | | | | | | | | This was originally based on some other code but its mostly misleading comments now. Massively clean this up and accept its now a total fork. There are no funciton changes here, just cleanup. (Bitbake rev: 3daa9001269e5b9156d0eb3299d2628d2d219fff) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: daemonize: Ensure child process exits safelyRichard Purdie2017-07-311-3/+8
| | | | | | | | | | | | | When we create the child, if an exception occurred it was transfering back into the parent context. We don't want to do that us use a try/finally to ensure we exit. We need to ensure a traceback is printed and any queued UI messages which may not have made it to the client UI at this point. (Bitbake rev: dec1d2c26f6cb3ffeb44beaab0129cd531a6d08b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: process: Add some extra server startup logsRichard Purdie2017-07-311-1/+4
| | | | | | | | | | We have cases where the server is being started but we're not seeing any messages from it. Add some earlier logging so we can try and better understand where issues may be occurring. (Bitbake rev: 10a6a48c0c5a2fe2051e90143e66075356853971) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: process: Reorder server command processing and handle EOFErrorRichard Purdie2017-07-311-13/+18
| | | | | | | | | | | | | If the connection control socket and the command channel close together, we can race and hit EOFError exceptions before we close the channel. Reorder the code to handle this in the correct order and ignore the EOFError exceptions as they mean the client is disconnecting and shouldn't terminate the server. (Bitbake rev: 974281ed72d8366baa16ee85f7e93970689b5956) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: wget: fix FusionForge workaroundRoss Burton2017-07-311-6/+3
| | | | | | | | | | | | | | | | | My previous assertion about FusionForge appears to have been wrong, or FusionForge has changed behaviour, or both. FusionForge now mandates that downloads have the Accept header set, despite that header being optional, and returns a 406 Not Acceptable error if it isn't set. As we were pretending that 406 was actually 405 (Moved) and tried to handle it as a redirect this results in an infinite loop until Python kills the recursion. Delete the handling of 406 as 405, and pass Accept: */* in the headers. (Bitbake rev: bb70ae0c9aac5ec688026d23a64ac0cac1947187) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: move to new bitbake xmlrpc defaultDavid Reyna2017-07-313-7/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | The bitbake option "-t SERVERTYPE" was deprecated and can be removed since the desired XMLRPC listener now the default. The bitbake server port cannot be "-1" anymore and must be explicitly passed. There is a race condition for the bblock file to not only be created but to actually be populated, so a delay test loop is required (usually only one pass). The 'xmlrpcclient' is now the class that allows Toaster to for example kill builds. The events for populating the recipe parsing now either show only the final result or are skipped entiredly, so the progress calculator needs to be changed to not block on the parsing phase. [YOCTO #11851] (Bitbake rev: 2aa7ad38f760ec003fb18faa5aa0014cff191a7a) Signed-off-by: David Reyna <David.Reyna@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-05-24 20:48:28 +0000