There are several issues: * there are several recipes which don't work when run under strace with parallelisation. * it's not integrated into our process and tested regularly * we have no known base data to compare against We need to determine a path for inclusion of swabber into our process and execute on it so that we can be aware of and fix host intrusion issues.
As a first stab at this I'd intend to deliver: * A list of recipes which don't work when run under strace * A report of known issues and a process (and if required, a tool) for comparing to the known base. * A plan for integration into our process and owning action of that plan For later I'd like to see: * Working with upstreams to fix the problematic recipes
(In reply to comment #1) > As a first stab at this I'd intend to deliver: > * A list of recipes which don't work when run under strace This should probably read "don't work well", namely - the recipes for which we have to explicitly disable parallelism in the swabber class (image-swab.bbclass).
Design Signed Off
Moved this one to M2 as Josh has been busy working on point releases. His M2 schedule looks fine with this change.
Having done some tidy up of this functionality I've discovered that the swabber report generation on larger are consuming large amounts of memory. ~6GB on a core-image-sato-sdk. I think we need to hold off on further work on this feature until swabbers memory consumption has been reduced.
Swabber is dead therefore closing this bug