linux/poky.git/bitbake/lib/bb, branch yocto-1.7.2

bitbake: lib/bb/utils: add safeguard against recursively deleting things we shouldn't

2015-04-24T10:33:13+00:00

Add some very basic safeguard against recursively deleting paths such as / and /home in the event of bugs or user mistakes. Addresses [YOCTO #7620]. (Bitbake master rev: 56cddeb9e1e4d249f84ccd6ef65db245636e38ea) (Bitbake rev: fbf1c39641f78d553961974a2bb96256eb9496e7) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: fetch/git: Remove a possible trailing '/' in subpath

2015-04-24T10:33:13+00:00

If the subpath parameter to the git fetcher ends with a trailing '/', bb.utils.prunedir() will be called on '/'... Fixes [YOCTO #7620]. (Bitbake master rev: 380a3fb372c8b0a53dd7528562e6e7a222dc76ef) (Bitbake rev: faffa1c4a4d8353b21a0d359076153da0dc31a05) Signed-off-by: Anders Darander Signed-off-by: Richard Purdie

bitbake: bitbake: tests/data: add test for incorrect remove behaviour

2015-04-15T14:56:06+00:00

The _remove operator isn't working correctly when used with a variable that expands to several items, so add a test case to exercise this path. (Bitbake rev: cb2a62a5fbffb358528a85b46c1fc6383286cb9d) (Bitbake rev: ed950f95fc80f069e800e9c6e785641f307e6512) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

bitbake: bitbake: data_smart: split expanded removal values when handling _remove

2015-04-15T14:56:06+00:00

Given these assignments: TEST="a b c d" TEST_remove = "b d" TEST evaluates to "a c". However, if the _remove override is given as a variable: TEST="a b c d" FOO = "b d" TEST_remove = "${FOO} TEST evaluates to "a b c d", because when FOO is expanded it isn't split into a list. Solve this by splitting all members of removeactive once they've been expanded. [ YOCTO #7272 ] (Bitbake rev: 207013b6dde82f9654f9be996695c8335b95a288) (Bitbake rev: c25b0e0ca289f6ad0ed697a0b0252fa48ab5dd0b) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

bitbake: data.py: fixes bad substitution when running devshell

2015-04-11T15:27:19+00:00

Running bitbake inside make results in the exported environment variable MAKEOVERRIDES="${-*-command-variables-*-}", which the shell chokes on when trying to expand it. But of course, it probably shouldn't have been trying to expand it in the first place -- so just escape the dollar sign. (Bitbake rev: 18cd0ce6a55c9065c3f1bf223b47d817b5efcd8f) (Bitbake rev: 34226a9e02f319a7547967bbdaca3ca918927dd1) Signed-off-by: Richard Tollerton Signed-off-by: Richard Purdie Signed-off-by: Alejandro Hernandez Signed-off-by: Richard Purdie

bitbake: cooker/server: Fix up 100% CPU usage at idle

2015-04-11T15:21:48+00:00

The recent inotify changes are causing a 100% cpu usage issue in the idle handlers. To avoid this, we update the idle functions to optionally report a float value which is the delay before the function needs to be called again. 1 second is fine for the inotify handler, in reality its more like 0.1s due to the default idle function sleep. This reverts performance regressions of 1.5 minutes on a kernel build and ~5-6 minutes on a image from scratch. (Bitbake rev: 0e0ba408c2dce14a0fabd3fdf61d8465a031495b) (Bitbake rev: 88dfe16b5abd804bae0c1e3b60cb93cb951cbc3f) Signed-off-by: Richard Purdie

bitbake: cooker: read file watches on server idle

2015-04-11T15:21:48+00:00

The inotify facility monitoring changes to the config files could be overwhelmed by massive changes to the watched files while server is running. This patch adds verification the notification watches to the server idle functions, in addition to the cooker updateCache command which executes only infrequently, thus preventing overflowing the notification buffer. [YOCTO #7316] (Bitbake rev: 996e663fd5c254292f44eca46f5fdc95af897f98) (Bitbake rev: b44694b1efc7389536df2f901a8b70321edfeeba) Signed-off-by: Alexandru DAMIAN Signed-off-by: Richard Purdie

bitbake: cooker: Improve pyinotify performance

2015-04-11T15:21:48+00:00

Benchmarks show that the introduction of pyinotify regressed performance. This patch ensures we only call the add_watch() function for new entries, not ones we've already processed which does improve performance as measured by "time bitbake -p". This doesn't completely remove the overhead but it does substantially reduce it. (Bitbake rev: 493361f35f6cc332d4ea359a2695622c2c91a9c2) (Bitbake rev: f668b347a8f9563f41d454288b9d4632190f308f) Signed-off-by: Richard Purdie

bitbake: cooker: Further optimise pyinotify

2015-04-11T15:21:47+00:00

We currently add crazy numbers of watches on files. The per user limit is 8192 by default and on a system handling multiple builds, this can be an issue. We don't need to watch all files individually, we can watch the directory containing the file instead. This gives better resource utilisation and better performance further reverting some of the performance regression seen with the introduction of pyinotify. (Bitbake rev: a2d441237916a99405b800c1a3dc39f860100a8c) (Bitbake rev: 6ab3945fc54b2a242292a874d78ebd8cccb99573) Signed-off-by: Richard Purdie

bitbake: cooker: Fix pyinotify handling of ENOENT issues

2015-04-11T15:21:47+00:00

We try and add watches for files that don't exist but if they did, would influence the parser. The parent directory of these files may not exist, in which case we need to watch any parent that does exist for changes. This change implements that fallback handling. (Bitbake rev: 979ddbe4b7340d7cf2f432f6b1eba1c58d55ff42) (Bitbake rev: 6d0abc6a5c9b8b37eecfa63fbcb5343162bc9311) Signed-off-by: Richard Purdie