Re: [PATCH v6 12/27] Detect false sharing of recipes

[Jan Kiszka <jan.kiszka@siemens.com>]

On 30.09.19 11:56, Baurzhan Ismagulov wrote:
> On Mon, Sep 30, 2019 at 08:00:21AM +0200, Jan Kiszka wrote:
>> isar-bootstrap had two issue:
>>
>> 1. Not rebuilding when it should (on changes to its configuration)
> 
> Was this due to the PF tweaking before your series, and is now fixed by your PF
> changes?

https://groups.google.com/d/msg/isar-users/nciPZ484-nI/kf9C-_9tAQAJ
(finding the right messing in googlegroups is a horrific mess...)

> 
> 
>> 2. False sharing of it deployment directory
> 
> Do you mean e.g. using tmp/deploy/bootstrap/debian-stretch-armhf for
> qemuarm-stretch and bananapi, in fact having different configurations (bananapi
> requesting the buster kernel)?
> 

https://groups.google.com/d/msg/isar-users/nciPZ484-nI/vjjYVf9tAQAJ

That bananapi was requesting a different bootstrap setting was a bug of its own, 
fixed by no longer doing that. Not triggered in CI because that target is not built.

> 
>> None of them were or could have been detected by this instrumentation.
> 
> I meant your whole series including the PF changes and bundled the questions in
> this reply, sorry for confusion.
> 
> 
>> What would have been detected AFTER removing that improper rebuild
>> prevention (https://groups.google.com/d/msgid/isar-users/ccad9eb9-fce5-89d1-3188-7043f003ea7e%40siemens.com)
>> is https://groups.google.com/d/msgid/isar-users/ccad9eb9-fce5-89d1-3188-7043f003ea7e%40siemens.com
>> - which is still not in your queue. Lost in your staging tree?
> 
> Not lost, no worries; two patches from the first series are still pending. I'd
> like to understand the failure mode because I'm also struggling with a race.
> Does the URL refer to [PATCH v2 09/26] meta-isar: Move bananapi to buster,
> remove bogus example? My browser opens the URL in the middle of a message.
> 

Yes, sorry, googlegroups... I thought the links you find at the bottom of each 
message would work, but they don't, at least in this thread.

> 
>>> 3. Where does this delete the once.* file w.r.t. e.g. do_dpkg_build for
>>>      different multiconfigs?
>>
>> At the beginning of the new build (parse_completed) or when a recipe failed
>> to build (task_failed).
> 
> Yes, this is what I also read from the patch. If I build hello-isar for e.g.
> qemuarm-buster and qemuamd64-buster, its do_dpkg_build is called for each
> multiconfig. Why doesn't it fail on once.do_dpkg_build? IIUC, parse_completed

If two multiconfs have the same common dependency, that one is only built once. 
Well, except when not. And when not, my instrumentation will tell you that there 
is a fundamental multiconf bug.

> has finished in the beginning and no recipes fail. The following output was
> taken with your instrumentation:
> 
> + bitbake -v multiconfig:qemuarm-stretch:isar-image-base multiconfig:qemuarm64-stretch:isar-image-base multiconfig:qemuamd64-stretch:isar-image-base multiconfig:qemuarm-buster:isar-image-base
> NOTE: Running task 306 of 404 (multiconfig:qemuarm-stretch:/workspace/build/isar_ibr_devel_fast/24/meta-isar/recipes-app/hello-isar/hello-isar.bb:do_dpkg_build)
> NOTE: recipe hello-isar-0.3-a18c14c-r0: task do_dpkg_build: Started
> NOTE: Running task 310 of 404 (multiconfig:qemuarm64-stretch:/workspace/build/isar_ibr_devel_fast/24/meta-isar/recipes-app/hello-isar/hello-isar.bb:do_dpkg_build)
> NOTE: recipe hello-isar-0.3-a18c14c-r0: task do_dpkg_build: Started
> NOTE: recipe hello-isar-0.3-a18c14c-r0: task do_dpkg_build: Succeeded
> NOTE: recipe hello-isar-0.3-a18c14c-r0: task do_dpkg_build: Succeeded
> 
> 
> With kind regards,
> Baurzhan.
> 

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux