linux/poky.git/bitbake, branch dunfell-next

bitbake: tests/fetch: Move away from problematic freedesktop.org urls

2020-09-18T18:14:26+00:00

We're either hitting rate limiting with freedesktop.org or the servers have intermittent network connections. Use our own mirror of these repositories instead. (Bitbake rev: 18e1957337fd9f06bc673d28dd4f8277321d07bc) Signed-off-by: Richard Purdie (cherry picked from commit a1b7ab5c9d5e64969f5ca0e41c0ac13c723e3761) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: fetch2: Drop cups.org from wget status checks

2020-09-17T11:29:50+00:00

Its becomming clear the upstream server doesn't like this, drop these two urls from the test, not sure we need them here anyway. (Bitbake rev: 16774d4d41f2011e8db7d2986a1a701df123dfc1) Signed-off-by: Richard Purdie (cherry picked from commit ab2ef942dc21f9639793c972f2e546edf9444783) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: siggen: clean_basepath: remove recipe full path when virtual:xyz present

2020-09-17T11:29:50+00:00

Before this fix, this example basepath (a): virtual:native:/full/path/to/recipes-example/helloworld/helloworld_1.2.3.bb:do_compile would get incorrectly "cleaned" into: helloworld/helloworld_1.2.3.bb:do_compile:virtual:native:/full/path/to/recipes-example/helloworld/helloworld_1.2.3.bb When searching backwards in `a` trying to isolate the 'virtual:xyz' to add it to the end of the string, we need to consider `a` still has the recipe path and taskname. So stoping the rsplit after only 1 split is not enough. We want to reach the second ':' from the end. This way, we obtain: helloworld/helloworld_1.2.3.bb:do_compile:virtual:native reviewed-by: Maxime Roussin-Bélanger (Bitbake rev: befc11acd25a9d9a2d44c20a0e33ada740407af7) Signed-off-by: Jean-Francois Dagenais Signed-off-by: Richard Purdie (cherry picked from commit d193d93422a0ad62aa35b5d4ca5da8d422f72180) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: server/process: Account for xmlrpc connections

2020-07-28T23:21:40+00:00

UI control can happen via the xmlrpc connection. Account for this when timing out UI connections. This was causing issues for toaster on systems where it couldn't parse the metadata within the timeout. (Bitbake rev: 838a89141fd6a75da9f982ad2b035e823b692d2a) Signed-off-by: Richard Purdie (cherry picked from commit fa85a8263971c25e67fa3b421c686a90e46acd87) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: server/process: Fix UI first connection tracking

2020-07-28T23:21:40+00:00

We're only meant to be doing UI connection timeouts on the first connection but haveui changes for each connection. We need to add a specific variable to track this correctly and get the intended behaviour. (Bitbake rev: fda107a4a1033ac7111a3289dbe6e48cea986927) Signed-off-by: Richard Purdie (cherry picked from commit e7c387c2e2fb2cc3ca1dc9d2029362909c326d72) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: cooker: Handle multiconfig name mappings correctly

2020-07-23T15:51:07+00:00

"bitbake mc:arm:bash mc:arm:busybox" works but "bitbake multiconfig:arm:bash multiconfig:arm:busybox" does not. The reason is the list is modified whilst iterating. Don't do that. [YOCTO #13607] (Bitbake rev: cc11dfa4eb3616547a8a3909f89da0cc4f35dc57) Signed-off-by: Richard Purdie

bitbake: server/process: Fix note reference -> info

2020-07-21T15:57:48+00:00

Its bb.note or logger.info, this avoids a backtrace. (Bitbake rev: fb80389d2ce62e15e354c6ea288c9a4bbe0040f6) Signed-off-by: Richard Purdie

bitbake: server/process: Ensure UI-less servers don't sit in infinite loops

2020-07-19T15:22:12+00:00

If server startup is broken for some reason (e.g. lockfile issues) and no UI connection is made, the server will just sit inifinitely waiting. Add a timeout upon startup in the non-memory resident case so that such infinite waits are avoided. In the memory resident case, the server wouldn't have shut down in the first place or will timeout according to configuration. Since any race may mean the socket file is no longer present, ensure the unlink doesn't fault upon exit, thus ensuring any hashequiv or PRServ is removed from memory, allowing all processes to exit cleanly in such scenarios. (Bitbake rev: 81cad9b8c4df15218d1a419c6b8e3ac73b54600c) Signed-off-by: Richard Purdie (cherry picked from commit 39888b750df12478e8bdea6727cca112dce1df85) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: server/process: Fix a rare lockfile race

2020-07-19T15:22:12+00:00

We're seeing rare occasional races on the autobuilder as if two server processes have the lockfile at the same time. We need to be extremely careful this does not happen. I think there is a potential race in this shutdown code since we delete the lockfile, then call unlockfile() which also tries to delete it. This means we may remove a lock file now held by another process if we're unlucky. Since unlockfile removes the lockfile when it can, just rely on that and remove any possible race window. An example cooker-deamonlog: --- Starting bitbake server pid 2266 at 2020-07-11 06:17:18.210777 --- Started bitbake server pid 2266 Entering server connection loop Accepting [] ([]) Processing Client Connecting Client Running command ['setFeatures', [2]] Running command ['updateConfig', XXX] Running command ['getVariable', 'BBINCLUDELOGS'] Running command ['getVariable', 'BBINCLUDELOGS_LINES'] Running command ['getSetVariable', 'BB_CONSOLELOG'] Running command ['getSetVariable', 'BB_LOGCONFIG'] Running command ['getUIHandlerNum'] Running command ['setEventMask', XXXX] Running command ['getVariable', 'BB_DEFAULT_TASK'] Running command ['setConfig', 'cmd', 'build'] Running command ['getVariable', 'BBTARGETS'] Running command ['parseFiles'] --- Starting bitbake server pid 8252 at 2020-07-11 06:17:28.584514 --- Started bitbake server pid 8252 --- Starting bitbake server pid 13278 at 2020-07-11 06:17:31.330635 --- Started bitbake server pid 13278 Running command ['dataStoreConnectorCmd', 0, 'getVar', ('BBMULTICONFIG',), {}] Running command ['getRecipes', ''] Running command ['clientComplete'] Processing Client Disconnecting Client No timeout, exiting. Exiting where it looks like there are two server processes running which should not be. In that build there was a process left sitting in memory with its bitbake.sock file missing but holding the lock (not sure why it wouldn't timeout/exit). (Bitbake rev: de919782f488a83b80d7c40896bf5b2596f1f65f) Signed-off-by: Richard Purdie (cherry picked from commit e1a7c1821483031b224a1570bfe834da755219cc) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: pyshyacc: allow double COMMA statements

2020-07-19T15:22:12+00:00

this allows shell statements like '; ;' to pass the parser. As it may be bad code but still valid enough to execute (Bitbake rev: 85a499f8915dd6596d56808e6e1c536015e4eb34) Signed-off-by: Konrad Weihmann Signed-off-by: Richard Purdie (cherry picked from commit b7732b1b5085bea73e17d112e1bd9ac3d4dc34fb) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie