10035 2016-07-26 21:02:26 +0000 oe-selftest: Use SSTATES without corrupting them. 2017-06-14 21:23:47 +0000 1 1 10 QA/Testing Build Testing general unspecified x86 Multiple VERIFIED DUPLICATE 10929 High enhancement 2.3 M3 10929 10937 1 mariano.lopez leonardo.sandoval.gonzalez benjamin.esquivel joshuagloe juan.fernandox.ramos.frayle leonardo.sandoval.gonzalez richard.purdie sgw jose.perez.carranza --- New (Never tested) Don't know oldest_to_newest 64513 0 mariano.lopez 2016-07-26 21:02:26 +0000 Currently the oe-selftest run takes a lot of time to complete in the autobuilders. A speed up can be from using SSTATES when building the images and the SDK; the problem is the test could corrupt the SSTATES, so a cache would be needed. 65649 1 leonardo.sandoval.gonzalez 2016-08-31 15:05:36 +0000 Due to time constrains, moving it to next enhancement window. 67946 2 benjamin.esquivel 2016-11-03 22:11:32 +0000 I would like to see how the SSTATES get corrupted, how can I check this out? 67953 3 mariano.lopez 2016-11-03 22:20:25 +0000 I have never actually seen this. I opened the bug because I was told that this was the reason for selftest not using SSTATES, I don't remember who said that. 68004 4 leonardo.sandoval.gonzalez 2016-11-04 21:23:10 +0000 (In reply to comment #3) > I have never actually seen this. I opened the bug because I was told that > this was the reason for selftest not using SSTATES, I don't remember who > said that. Mariano, I believe 'corrupted' means that the shared states are touched by the selftests thus effectively changing the state. 68029 5 benjamin.esquivel 2016-11-07 17:50:54 +0000 (In reply to comment #4) > > Mariano, I believe 'corrupted' means that the shared states are touched by > the selftests thus effectively changing the state. This bug was filed as a result of a comment from RP and we've already discussed what corrupted means and it doesn't look like corrupted = changed in this case. 68030 6 richard.purdie 2016-11-07 17:54:21 +0000 Corrupted here means that sstate gets deleted. Nothing on the autobuilder should run a "-c cleansstate". The issue is that a build can be part way through running having checked sstate exists, then it can find it no longer does whilst its trying to use it. 68031 7 richard.purdie 2016-11-07 17:55:45 +0000 We could just use the sstate as a read only mirror for oe-selftest to ensure that it can't delete things. Where a test needs to run an sstate clean, it could use "-f" to force a taint to a hash instead? 68042 8 benjamin.esquivel 2016-11-07 19:48:55 +0000 (In reply to comment #7) > We could just use the sstate as a read only mirror for oe-selftest to ensure > that it can't delete things. Where a test needs to run an sstate clean, it > could use "-f" to force a taint to a hash instead? thanks for the clarification Richard. Mariano, this looks like a way to start the investigation on this bug. 68511 9 benjamin.esquivel 2016-11-22 20:45:02 +0000 Assigning it to Leo whom will try to get it done for M1. 70084 10 leonardo.sandoval.gonzalez 2017-01-24 16:25:20 +0000 The is a newer bug (10929), filed by RP reporting an symptom of the main problem. Benjamin did some work on 10929 thus is more advance that this one. Making this as duplicated of 10929. *** This bug has been marked as a duplicate of bug 10929 *** 74173 11 juan.fernandox.ramos.frayle 2017-06-14 21:23:47 +0000 Verified, tested with commit b6a1004c73820cff833f2b6f09d2432706f5447a, no SSTATES were corrupted after selftest