linux/poky.git, branch honister-3.4

build-appliance-image: Update to honister head revision

2021-10-11T10:06:51+00:00

(From OE-Core rev: bb1dea6806f084364b6017db2567f438e805aef0) Signed-off-by: Richard Purdie

bitbake: bitbake: Bump to version 1.52.0

2021-10-11T10:06:18+00:00

(Bitbake rev: c78ebac71ec976fdf27ea24767057882870f5c60) Signed-off-by: Richard Purdie

build-appliance-image: Update to honister head revision

2021-10-11T10:04:32+00:00

(From OE-Core rev: b3c387547c8b73ef134e6665e18bd4724d943133) Signed-off-by: Richard Purdie

poky.conf: Bump version for 3.4 honister release

2021-10-11T10:03:45+00:00

(From meta-yocto rev: fc8c4b3b6bb0798edd4ac32c3c19a553a15b5749) Signed-off-by: Richard Purdie

bitbake: hashserv: Improve behaviour for better determinism/sstate reuse

2021-10-11T10:00:06+00:00

We have a choice of policy with hashequivalence - whether to reduce sstate duplication in the sstate feed to a minimum or have maximal sstate reuse from the user's perspective. The challenge is that non-matching outhashes are generated due to determinism issues, or due to differences in host gcc version, architecture and so on and the question is how to reconcile then. The approach before this patch is that any new match is added and matches can update. This has the side effect that a queried value from the server can change due to the replacement and you may not always get the same value from the server. With the client side caching bitbake has, this can be suboptimal and when using the autobuilder sstate feed, it results in poor artefact reuse. This patch switches to the other possible behaviour, once a hash is assigned, it doesn't change. This means some sstate artefacts may be duplicated but dependency chains aren't invalidated which I suspect may give better overall performance. Update the tests to match the new behaviour. (Bitbake rev: 20d6ac753efa364349100cdc863e5eabec8e5b78) Signed-off-by: Richard Purdie

bitbake: hashserv: Fix diverging report race condition

2021-10-11T10:00:06+00:00

Fixes the hashequivalence server to resolve the diverging report race error. This error occurs when the same task(hash) is run simultaneous on two different builders, and then the results are reported back but the hashes diverge (e.g. have different outhashes), and one outhash is equivalent to a hash and another is not. If taskhash was not originally in the database, the client will fallback to using the taskhash as the suggested unihash and the server will see reports come in like: taskhash: A unihash: A outhash: B taskhash: C unihash: C outhash: B taskhash: C unihash: C outhash: D Note that the second and third reports are the same taskhash, with diverging outhashes. Taskhash C should be equivalent to taskhash (and unihash) A because they share an outhash B, but the server would not do this when tasks were reported in the order shown. It became clear while trying to fix this that single large table to store all reported hashes was going to make these updates difficult since updating the unihash of all entries would be complex and time consuming. Instead, it makes more sense to split apart the database into two tables: One that maps taskhashes to unihashes and one that maps outhashes to taskhashes. This should hopefully improve the parsing query times as well since they only care about the taskhashes to unihashes table, at the cost of more complex INNER JOIN queries on the lesser used API. Note this change does delete existing hash equivlance data and starts a new database table rather than converting existing data. (Bitbake rev: dff5a17558e2476064e85f35bad1fd65fec23600) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie

bitbake: hashserv: Add tests for diverging reports

2021-10-11T10:00:06+00:00

(Bitbake rev: 953c8d622c9d1bc1eb06bcaf1eaa3aa9f85d0bc2) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie

bitbake: async: Close sync client event loop

2021-10-11T10:00:06+00:00

Prevents `ResourceWarning: unclosed event loop` warnings when using the synchronous client and python exits (Bitbake rev: 8b95972bc04ce52a98c7780184af15a5e95f987b) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie

ptest-runner: install -collect-system-data script

2021-10-09T16:21:47+00:00

When ptest-runner times out or otherwise fails, it tries to call ptest-runner-collect-system-data, so install the script. The script currently calls dmesg, df, free (which are provided by busybox, etc.) and pstree (which is a sub-package of psmisc). Add pstree as an RDEPENDS. (From OE-Core rev: 4e6be3fb521b23cfc175d0c09725bcc3ebbc73b2) Signed-off-by: Tim Orling Signed-off-by: Richard Purdie

glibc: Drop libcidn package

2021-10-09T16:21:47+00:00

libcidn has been dropped since glibc 2.28 (From OE-Core rev: cf83790728ad569af01300f793754c0108c78b4e) Signed-off-by: Fred Liu Signed-off-by: Richard Purdie