The "Part 3" patch, which was landed three times before it stuck, required a clobber for what appear to be two unrelated reasons. 1) Without a clobber, the Android build would fail. The symptom here is that the builder attempted to compile the Linux portability layer in media/webrtc/signaling/src/sipcc/cpr/linux rather than the Android compatibility layer in media/webrtc/signaling/src/sipcc/cpr/android. See https://tbpl.mozilla.org/php/getParsedLog.php?id=23874186&tree=Mozilla-Inbound 2) Without a clobber, mochitest-3 and crashtest would fail on all platforms (but this is probably my fault; see below). Here are TBPL entries for this patch, in chronological order: a) Try: https://tbpl.mozilla.org/?tree=Try&rev=17d40635ff27 b) m-i: https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=8ec73e6aa7d3 c) Try: https://tbpl.mozilla.org/?tree=Try&rev=237234896a59 d) m-i: https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=263154173cc8 e) m-i: https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=ca78349dea64 Notes: a) shows Android building clean on Try. c) shows Android building clean on Try. d) shows Android build burning on m-i. Phil Ringnalda performed a manual clobber and restarted the Android build, after which it worked. e) Is a clean landing, after touching CLOBBER. In my own postmortem, I suspect that the mochi/crash failures are related to a failure to update the UUID in a changed IDL file (I can't believe I missed that), so they probably don't warrant further investigation. However, the Android build failure appears to be an actual bug. The only makesystem change for this patch is the addition of fsmdef_states.h to media/webrtc/signaling/signaling.gyp. It is unclear how this change could result in using the wrong set of source files for the compilation.
You need to log in before you can comment on or make changes to this bug.