summaryrefslogtreecommitdiffstats
path: root/bitbake/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* bitbake: utils: Fix BB_PRESERVE_ENVRichard Purdie2013-09-111-0/+2
| | | | | | | | | | | BB_PRESERVE_ENV wasn't working since data.inheritFromOS wasn't getting a correct list of keys to import into the data store. This fixes things so it does add all environment variables into the data store when BB_PRESERVE_ENV is used. (Bitbake rev: 843e9339c5ee3c99657a40a0e2c7dbd777b6ef06) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: runqueue: add sceneQueueTaskCompleted eventAlexandru DAMIAN2013-09-101-0/+6
| | | | | | | | | | | Adding an event to be fired when a scene task is completed. It is analogous to the run task completed event, and has been missing for some reason. (Bitbake rev: 73b8f4d3fbeaf1b330a66d76012d0a5cef8dbe2d) Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue.py: check whether multiple versions of the same PN are due ↵Robert Yang2013-09-091-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to be built There would be an race issue if we: $ bitbake make-3.81 make-3.82 This because they are being built at the same time which would cause unexpected problems, for example: [snip] ERROR: Package already staged (/path/to/tmp/sstate-control/manifest-qemux86-make.populate-sysroot)?! ERROR: Function failed: sstate_task_postfunc [snip] Or there would be python's strack trace such as: [snip] *** 0004: mfile = open(manifest) 0005: entries = mfile.readlines() 0006: mfile.close() 0007: 0008: for entry in entries: Exception: IOError: [Errno 2] No such file or directory: xxx [snip] [YOCTO #5094] We can quit earlier to avoid this kind of issue when two versions of the same PN are going to be built since this isn't supported. (Bitbake rev: ab377c00c33a2d296bfda1b0b6c2a62b29d1004f) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: providers.py: enhance the runtime debug degbug messgaeRobert Yang2013-09-091-1/+1
| | | | | | | | | | | | The runtime provider debug message is the same as the build time debug message, make them different would be better. [YOCTO #5067] (Bitbake rev: 92b624cbc2711d3d859994099fb63918dfd0031a) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: prserv: Ensure data is committedRichard Purdie2013-09-082-1/+6
| | | | | | | | | | | | In exclusive mode, we need to complete the transaction for writes to make it to the database. Therefore add sync calls to ensure this happens. Autocommit mode is significantly (100 times) slower so caching the data is of significant benefit. (Bitbake rev: 4e55f7821786a59c2cd7dbd8bfa2a22f5f196e99) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: Reduce refresh of footerRichard Purdie2013-09-061-2/+4
| | | | | | | | | | | When displaying larger number of events the client can get caught up in displaying the footer, then immediately overwriting it. To avoid this, wait for pauses in the event stream before displaying the footer to give a slightly more friendly feel to the UI. (Bitbake rev: 5d706c7cd6ee8d83b67ff18312d4c8119bea8878) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Ensure ${DATE} and ${TIME} are consistentPeter Kjellerstedt2013-09-061-0/+2
| | | | | | | | | | | | | | | Due to the worker split the ${DATE} and ${TIME} variables could end up with different values for different workers. E.g., a task like do_rootfs that is run within a fakeroot environment had a slightly different view of the time than another task that was not fakerooted which made it impossible to correctly refer to the image generated by do_rootfs from the other task. (Bitbake rev: 756cc69ebf8bfe8455d0c90f288dd51be2499773) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hob: remove custom image from the images list when not neededCristiana Voicu2013-09-061-0/+4
| | | | | | | | | | | | | Selected custom image recipes should be cleared from the combo the moment you change your selection. The idea is to always perform the selection of those images in the same way (i.e through the "Select from my image recipes" option). [YOCTO #5001] (Bitbake rev: 94483ee5ae9f4051bccd660c4718c36564e17161) Signed-off-by: Cristiana Voicu <cristiana.voicu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hob: limit the description size when a custom image is savedCristiana Voicu2013-09-061-2/+11
| | | | | | | | [YOCTO #5003] (Bitbake rev: 9aec9ee41d4d893325d9bf92b8a53f2e68e4973d) Signed-off-by: Cristiana Voicu <cristiana.voicu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data_smart: Move getVar expand cache handing to fix _remove operationsRichard Purdie2013-09-061-7/+6
| | | | | | | | | | | | | DISTRO_FEATURES_remove = "opengl" wasn't working as expected. The reason turned out the be the indirect reference to opengl and the fact _remove was operating on unexpanded data. This patch rearranges some code to ensure we operate on expanded data by moving the expand cache handing into getVarFlags instead of getVar. (Bitbake rev: 181899bd9665f74f8d1b22d2453616ad30d26d9e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hob: remove PACKAGE_INSTALL variable setting from hobCristiana Voicu2013-09-041-3/+1
| | | | | | | | | | | | | | Before saving the packages for a custom images in a .bb file, the packages were saved in bitbake memory. Now all the variables are saved in conf file, so saving PACKAGE_INSTALL is not needed anymore. Moved were LINGUAS_INSTALL is set, because both conditions are for testing if a custom image is saved. [YOCTO #5101] (Bitbake rev: 8757f962b92e7668f40d2d8bd9e762b152f91f7b) Signed-off-by: Cristiana Voicu <cristiana.voicu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-worker: ensure BUILDNAME is available during executionPaul Eggleton2013-09-041-0/+1
| | | | | | | | | | | | | | | BUILDNAME is set from cooker by default, so since the worker split it will not be set when executing functions. In OpenEmbedded this results in /etc/version (which is populated from BUILDNAME) not having any content. Pass this variable value through to the worker explicitly to fix the issue. Fixes [YOCTO #4818]. (Bitbake rev: 92940b0427d9b2b3f95e27c230ec1e36638a34bc) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake/cooker: fix some calls of cookerdata.findConfigFile methodCristiana Voicu2013-09-021-3/+3
| | | | | | | | | Cookerdata.findconfigFile method has a new parameter. Changed some calls. (Bitbake rev: dce0f9d4afe0986e2dd0146944fc4ac9dde275e4) Signed-off-by: Cristiana Voicu <cristiana.voicu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Fix scenequeue to pass file descriptors, not a floatRichard Purdie2013-09-021-1/+1
| | | | | | | | This was missed off in a previous patch. (Bitbake rev: ad7664edd40fa46e6f6fec2144403e3b6fc3a639) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/xmlrpc: stop server on client exitAlexandru DAMIAN2013-09-011-0/+5
| | | | | | | | | | | | If the server only expects a single client to connect (i.e. no bind parameter set, so there is no way for the clients to get the server port), stop the server after the first client exits. (Bitbake rev: eb6bae56f62082bf147045311154cbae4bca0f4c) Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: prserv/serv: Settle on two threads for optimal performanceRichard Purdie2013-09-011-14/+34
| | | | | | | | | | | | Using the threading mixin class resulted in large amounts of memory being used by the PR server for no good reason. Using a receiver thread and a thread to do the actual database operations on a single connection gives the same performance with a much saner memory overhead so switch to this. (Bitbake rev: e08455d5f3b8e96765942b9c3b9767c30650557d) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: build: Fix profile file namesRichard Purdie2013-09-011-1/+1
| | | | | | | | | | | | | Using the basename of the .bb file is not unique, for example xxx-native and xxx can overwrite each other. If this happens whilst running, you can get odd backtraces as one file is parsed as another tries to write out new data. Avoid issues by using PN for the output filename instead. (Bitbake rev: c9534f8e59d44b885334607ed90a3be2e492ec69) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: serv/db: Don't use BEGIN/COMMITRichard Purdie2013-09-011-13/+3
| | | | | | | | | | Since we don't support using multiple servers on the same database file, don't use the BEGIN/COMMIT syntax and allow writes to the database to work ~100 times faster with no transaction locking. (Bitbake rev: 42144a54979658f93fbbb43f7e271c1fff4d88ff) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: serv/db: Take an excluside lock on the databaseRichard Purdie2013-09-011-1/+1
| | | | | | | | | We only support one server using the database at a time so take an exclusive lock and avoid later lock overhead. (Bitbake rev: e3e39be6f2d063858c92971ce8ccd89c95d4f26d) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: serv/db: Fix looping upon database locked issuesRichard Purdie2013-09-011-3/+4
| | | | | | | | | | | | | If the database is locked we will get an immediate error indicating so, there is no retry timeout. The looping code is therefore useless, the loop count is near instantly exceeded. Using a time based retry means we can wait a sensible time, then gracefully exit. (Bitbake rev: 9f9e6d87007ea87e62495705464f4232c996a165) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/process, server/xmlrpc, runqueue: Use select.select() on ↵Richard Purdie2013-09-013-21/+28
| | | | | | | | | | | | | | | | | | | | | | fds, not time.sleep() The existing backend server implementations were inefficient since they were sleeping for the full length of the timeouts rather than being woken when there was data ready for them. It was assumed they would wake and perhaps did when we forked processes directory but that is no longer the case. This updates both the process and xmlrpc backends to wait using select(). This does mean we need to pass the file descriptors to wait on from the internals who know which these file descriptors are but this is a logical improvement. Tests of a pathaolgical load on the process server of ~420 rapid tasks executed on a server with BB_NUMBER_THREAD=48 went from a wall clock measurement of the overall command execution time of 75s to a much more reasonable 24s. (Bitbake rev: 9bee497960889d9baa0a4284d79a384b18a8e826) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: prserv: Allow 'table is locked' matching for retry loopRichard Purdie2013-08-301-1/+1
| | | | | | | | | Try and avoid errors like "ERROR: database table is locked: PRMAIN_nohist" by retrying if we see the string "is locked". (Bitbake rev: 1a175b51f80d13f747b653d29e9c0d2201b5109c) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/xmlrpc: Increase timeout to 60sRichard Purdie2013-08-301-1/+1
| | | | | | | | | | | | This is a better value that the earlier infinite timeout yet still allows for servers with high loads. It does mean the bitbake process can hang at exit for the timeout period but that should never happen and only happened for me in some test cases which wouldn't happen in normal use. (Bitbake rev: ab8d926b9bc27c58011e7db9327e031ac76ba34b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: Allow bblayers.conf to be found using BBPATHRichard Purdie2013-08-301-8/+15
| | | | | | | | | | | | | | | It should be possible to run a build anywhere on the filesystem and have bitbake find the correct build directory if its set somehow. The BBPATH variable makes perfect sense for this usage. Therefore use any available value of BBPATH to search for conf/bblayers.conf before walking the parent directory structure. This restores the option of being able to run bitbake from anywhere if the user has set things up to operate in that environment. (Bitbake rev: e86336b3fe245bc97fe74c9b9d6a21d38a536fb7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: Set TOPDIR when using bblayers.confRichard Purdie2013-08-301-0/+3
| | | | | | | | | | | | | By definition, bblayers.conf is at the top of the build tree. We'd like to support running bitbake anywhere within that build tree but TOPDIR gets set to wherever cwd is. Change the code to reset TOPDIR to the top of the build directory. This shouldn't break anything but does make the system more usable. (Bitbake rev: b266db27de0bba19a418e4d42e870649136b116b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: prserv/serv: Multithread the serverRichard Purdie2013-08-291-9/+15
| | | | | | | | | | | | | | | This makes the PR server multithreaded and able to handle multiple connections at once which means its no longer a build bottle neck when serving one connection at a time. I've experimented and database connection for each thread seems to cause the least issues, pushing the contention for sqllite to handle itself. This means moving the db/table connection code into the actual function methods. It doesn't abstract well as a function since we need the db object around for the lifetime of the function as well as the table else we lose the connection. (Bitbake rev: bf9be2029b2bded5f532bdda4c38ae3dff5d1cf6) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: prserv/db: Threading fixesRichard Purdie2013-08-292-4/+4
| | | | | | | | | | | | | | | | | Enabling threading for the PRServer causes a number of issues. Firstly is the obtuse error: sqlite3.InterfaceError: Error binding parameter 0 - probably unsupported type which is due to the class not being derived from object. See: http://docs.python.org/2/library/sqlite3.html#registering-an-adapter-callable Secondly, we want to enable multithreadded access to the database so we do this when we open it. This opens the way up to multithreading the PR server. (Bitbake rev: 5709efc2ff1e36529bd28f49cd093ccfa7abff7f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: serv.py: Fix regression from 972bc43e6d5bJason Wessel2013-08-281-1/+1
| | | | | | | | | | | | | | | commit 972bc43e6d5b1207b944b3baa8f9805adb35dda7 (serv.py: Fix hang when spawned dynamically with bitbake) introduced a regression, because the wrong patch was submitted. The syntax was incorrect in the original patch. The logger iterator must be used with a call to getLogger(). [YOCTO #5059] (Bitbake rev: 85fed8acc3af3e15bf119db2f51c486a9de3646b) Signed-off-by: Jason Wessel <jason.wessel@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data_smart: allow removal of multiple words at once with _removeChristopher Larson2013-08-281-1/+1
| | | | | | | | | | FOO = "foo bar baz" FOO_remove = "foo baz" (Bitbake rev: 04127dec207d6dfc0ada56c5cc67ec9ad30517a8) Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data_smart: use a split/filter/rejoin for _removeChristopher Larson2013-08-281-7/+3
| | | | | | | | | | | This is more idiomatic, and from the limited performance testing I did, is faster as well. See https://gist.github.com/kergoth/6360248 for the naive benchmark. (Bitbake rev: 1aa49226d5a2bac911feeb90e3d9f19529bc1a3e) Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: serv.py: Fix hang when spawned dynamically with bitbakeJason Wessel2013-08-281-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PRServer has the possibility to hang indefinitely blocking on a semaphore processing a xmlrpc request to send an event back to the main bitbake instance. This was observed during a "bitbake -e" on a heavily loaded machine and the main bitbake instance and cooker exited before the PRServer emitted its first log. The stack trace is provided below as to show what happens every time a logger.info() is executed in the PRServer. Not only does it write to the stream handler but it also tries to send the event to the main event processor. self._notempty.acquire() self.queue.put(event) _ui_handlers[h].event.send(event) fire_ui_handlers(event, d) fire(record, None) self.emit(record) hdlr.handle(record) self.callHandlers(record) self.handle(record) self._log(INFO, msg, args, **kwargs) (self.dbfile, self.host, self.port, str(os.getpid()))) self.work_forever() pid = self.daemonize() self.prserv.start() singleton.start() self.prhost = prserv.serv.auto_start(self.data) cooker.pre_serve() bb.cooker.server_main(self.cooker, self.main) self.run() code = process_obj._bootstrap() self._popen = Popen(self) self.serverImpl.start() server.detach() server = start_server(servermodule, configParams, configuration) ret = main() It was never intended for the PRServer to send its logs anywhere but its own log file. The event processing is an artifact of how the PRServer was forked and it inherits the event log handlers. The simple fix is to clean up and purge all the log handlers after the fork() but before doing any of the typical PRServer work or logging. (Bitbake rev: 972bc43e6d5b1207b944b3baa8f9805adb35dda7) Signed-off-by: Jason Wessel <jason.wessel@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hob: fixes for image combo boxCristiana Voicu2013-08-271-5/+4
| | | | | | | | | | | When an image from scratch is selected, and recipes parsing is canceled, the image shown by the combo box isn't correct. [YOCTO #5000] (Bitbake rev: f8166ace0bd9155199166990ce15da24eb2e793b) Signed-off-by: Cristiana Voicu <cristiana.voicu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hob: add event handlers filtering in HobCristiana Voicu2013-08-271-0/+15
| | | | | | | | | | Create the _evt_list for hob; it is longer than the knotty uses because it handles more events. (Bitbake rev: 715aed74f972bb6e9b6a5130ca9ede48d4f79f0a) Signed-off-by: Cristiana Voicu <cristiana.voicu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake/event.py: UIhandler filter should work without a maskCristiana Voicu2013-08-271-1/+1
| | | | | | | | | The default for the mask will be * (all the handlers) (Bitbake rev: 4c95e5f46cf2a656100bbf5a0e5a09d506abf9b9) Signed-off-by: Cristiana Voicu <cristiana.voicu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: command.py: Call updateCache for all states != runningRichard Purdie2013-08-262-2/+2
| | | | | | | | | | | updateCache handles the logic for shutting down the parsing so we need to call it for all cases when we're not running. This fixes hangs if Ctrl+C is pressed during parsing. (Bitbake rev: 552b8935dd2f9f11e8d5c08a597a7e966b891480) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data_smart: Add _remove operatorRichard Purdie2013-08-261-5/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | There are long standing complaints about the fact its very difficult to remove a portion of a variable. The immediate request is for a -= and =- operator. The trouble is that += and =+ are "immediate" operators and are applied straight away. Most people would expect -= and =- to be deferred to have the effect most people desire and therefore implementing -= and =- would just make the situation more confusing. This deferred operation is much more similar to the override syntax which happens at data store finalisation. The _remove operator is therefore in keeping with the _append and _prepend operations. This code is loosely based on a patch from Peter Seebach although it has been rewritten to be simpler, more efficient and avoid some potential bugs. The code currently only works on space delimited variables, which are by far the most commom type. If bitbake is ehanced to support types natively in future, we can adjust this code to adapt to that. (Bitbake rev: 9c91948e10df278dad4832487fa56888cd58d187) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Add ui event handlers filteringRichard Purdie2013-08-265-8/+46
| | | | | | | | | | | | | | | | | | | Add functionality to allow UIs to update and change the types of events they recieve. To do this we need to add a new command and also need to be able to obtain the current event hander ID. In the case of xmlrpc, this is straightforward, in the case of the process server we need to save the result in a multiprocessing.Value() so we can retrive it. An excplit command was added to the server API to facilitate this. The same function can also be used to mask or unmask specific log messages, allowing the UI to optionally differ from the standard set of message filtering. Based upon work by Cristiana Voicu <cristiana.voicu@intel.com> (Bitbake rev: ba5a6c88785d9889d4172ec79937ac2a5555327e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/xmlrpc/prserv: Add sane timeout to default xmlrpc serverRichard Purdie2013-08-262-7/+18
| | | | | | | | | | | | | | | | | The standard python socket connect has long timouts which make sense for remote connections but not local things like the PR Service. This adds a timeout parameter to the common xmlrpc server creation function and sets it to a more reasonable 5 seconds. Making the PR server instantly exit is a good way to test the effect of this on bitbake. We can remove the bodged timeout in the PRServer terminate function which has the side effect of affecting global scope. (Bitbake rev: 8c01cff94787abbb64fbdf0c16cd63f8f97a7e03) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: process: Improve exit handling and hangsRichard Purdie2013-08-261-19/+17
| | | | | | | | | | | | | | | | | | | | | | | It turns out we have a number of different ways the process server termination can hang. If we call cancel_join_thread() on the event queue, it means that it can be left containing partial data. This means the reading of the event queue in the terminate() function can hang, the timeout and block parameters to Queue.get() don't make any difference. Equally, if we don't call cancel_join_thread(), the join_thread in terminate() will hang giving a different deadlock. The best solution I could find is to loop over the process is_alive() after requesting it stops, trying to join the thread and if that fails, try and flush the event queue again. It wasn't clear what difference a force option should make in this case, we're gracefully trying to empty queues and shut down regardless of whether its a SIGTERM so I've simply removed the force option. (Bitbake rev: c5c8f33ca4b81877a0115887849881001b745bf0) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: parse: Return IOError when including file with absolute pathMartin Jansa2013-08-262-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * resolve_file was behaving different when relative and absolute paths were passed to it * include relative-path/non-existent-file.inc works correctly resolve_file throws IOError, BBHandler.py:handle() doesn't catch it, ConfHandler.py:include() catches IOError and shows: DEBUG: CONF file 'relative-path/non-existent-file.inc' not found * include /absolute-path/non-existent-file.inc was failing, because resolve_file just returns fn, BBHandler.py:handle() calls bb.parse.mark_dependency(d, abs_fn) which throws: OSError: [Errno 2] No such file or directory: '/absolute-path/non-existent-file.inc' and parsing fails. Ad isfile() test for absolute fn and throw IOError to make resolve_file behavior consistent for both paths. * I know we had some issues with -b relative-path-to-recipe.bb and absolute path, so consider this patch only as RFC and documentation of this problem * Catch OSError too in ConfHandler.py:include() e.g. in case the file exists, but user cannot read it or something like that. (Bitbake rev: b0bbd89a4f0b98fa1ab28b8e0526cd9ddb76fa57) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: prserv/serv: Fix pid file removalRichard Purdie2013-08-231-1/+1
| | | | | | | | | | Mark Hatle spotted there were pid files being left around. This patch fixes things so the removal function is called correctly, the code contained a typo. (Bitbake rev: c696a16c8200c31c52750037eeafe07e065b6517) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: event/msg: Add primitive server side UI log record filteringRichard Purdie2013-08-232-2/+30
| | | | | | | | | | | | | | | | | | | | Currently one of the bigger bottlenecks in bitbake is passing all the log messages over IPC to the UI. This is worthwhile if the UI is going to use them, pointless otherwise. The memory resident bitbake suffers from this performance issue particularly badly. This patch filters the log events on the server side with the global log levels and hence reduces the traffic. This speeds up parsing (18.5s down to 17s) and bitbake general command overhead is reduced (7.3s for a NOP to 6.2s). What isn't added here is general event filtering or the ability to change the log levels once set. Provision is made for adding this in a follow up patch though. (Bitbake rev: 1bf0e88f57ba0bca62532e81d0d62cf88e2abcbb) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: build.py: create symlink for run.do_xxx scriptsNicolas Dechesne2013-08-231-0/+14
| | | | | | | | | | | | | | | | | | | | | | The 'courtesy' symlink for log.do_xxx are quite useful when debugging, so with this commit, we now get similar 'courtesy' symlink for run.do_xxx scripts. We only create symlink for tasks, not individual functions. The symlink is create right before the actual runfile is created, indeed we cannot create the symlink right after running the task since a failure or execption can happen, in which case the symlink wouldn't be created, and symlink are particularely useful when the task failed! Another option would be create the symlink after the runfile is created, and before the script is executed, but that means we need to duplicate the code in case of Shell vs Python task. (Bitbake rev: a672b39c5d529ba85d72eee8fef4c4273eaa5397) Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hob: changes to image combo box from image configuration pageCristiana Voicu2013-08-221-1/+3
| | | | | | | | | | | | | | | | In some cases when a new machine is selected, the image combo shows the same option. Fixed this issue, because the image combo box should be reseted. Fix the counter for the options in the combobox. This bug was introduced by the templates functionality. The combo box had some last changes, and I forgot about this counter. [YOCTO #4858 & #5000] (Bitbake rev: 457fd80ee6b1b2bcef463e3a83e048da2f8bf805) Signed-off-by: Cristiana Voicu <cristiana.voicu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: propertydialog.py : Scrollable windows for long tooltipsAndrei Dinu2013-08-221-25/+38
| | | | | | | | | | | | | | In some cases, the length of the description and the brought in by field was too big. That led to the size of the property dialog exceeding Hob's size. For long tooltips we use scrollable windows now. [HOB #4321] (Bitbake rev: 78ecabf19bf01e5a662b6e2b865cd93bf47d962b) Signed-off-by: Andrei Dinu <andrei.adrianx.dinu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: build.py: Provide useful diagnostics when exiting.Peter Seebach2013-08-201-1/+24
| | | | | | | | | | | Running scripts with 'set -e' produces silent failures with no diagnostic. Add an exit handler which produces diagnostics, including details of what was running if the shell seems to be bash. (Bitbake rev: e213e6a4c297a4f1c22eed15bd7b4cbc0e9eab4f) Signed-off-by: Peter Seebach <peter.seebach@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hob/retrieveimagedialog: change labelsCristiana Voicu2013-08-161-1/+3
| | | | | | | | | | Some labels needed to be changed in order to respect the convention. [YOCTO #4999] (Bitbake rev: 110b485eac6adea242297b7942da8710403c465a) Signed-off-by: Cristiana Voicu <cristiana.voicu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: taskdata: report close matches with NoProvider errorsPaul Eggleton2013-08-164-6/+29
| | | | | | | | | | | Assuming there is no known reason why an item is not provided, show close matches on the assumption that it might have been a typo or other mistake. (Bitbake rev: ed81b0856b4a3892b53d39871eaaa6273390ea75) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: report close matches for an invalid task namePaul Eggleton2013-08-161-1/+7
| | | | | | | | | | Help to pick up mistakes such as "bitbake -c cleanstate xyz" (instead of "bitbake -c cleansstate xyz".) (Bitbake rev: 15c3db1cffdffd85641c6b12e77f19ce7a553472) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hob: Add missing file from previous commitRichard Purdie2013-08-121-0/+49
| | | | | | | | | | This should have been part of 'hob: implement the "retrieve image dialog" + changes to image combo box' but got lost in the merge process. This adds the missing file. (Bitbake rev: 0eadcc073f270c0b323955cf7719b77195cf4890) 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 01:36:06 +0000