A BUG on tryserver (?) Careful analysis of the failure in the C-C TB tryserver log reveals that tryserver does not seem to follow the desired order of patches for M-C portion of the tree.
Since there are couple of patches that touch the same file, they must be applied in a certain order. But I don't think tryserver is following the order I want it follow. (Hmm, I have never seen such a behavior before when the jobs was submitted more than a couple of years ago. The patches are created using the shell script that I wrote a few years ago and used successfully. But maybe something changed in the patch submission procedure or something.) This is the order of the patches I want tryserver to apply under M-C portion of the tree. (output of hg qser -v) 0 A do-not-call-FcFini-because-it-crashes-due-to-failure-to-release.patch 1 A intl-icu-debug.patch 2 A ns-error-code-mapping.patch 3 A add-error-check-to-read.patch 4 A error-code-trace-for-write-read.patch 5 A negative-error-code-processing.patch 6 A buffer-setup.patch 7 A better-error-nsBufferedStreams.patch 8 A NS_FillArray-short-read-issue.patch 9 A cacheblock-short-read.patch 10 A ReadPluginInfo-short-read.patch and these are recorded in in C-C tree as in: (again |hg qser -v| output.) ... 6 A 1116055-acelist.patch 7 A add-short-read-handling.patch 8 A mozilla-M-C-do-not-call-FcFini-because-it-crashes-due-to-failure-to-release.patch 9 A mozilla-M-C-intl-icu-debug.patch 10 A mozilla-M-C-ns-error-code-mapping.patch 11 A mozilla-M-C-add-error-check-to-read.patch 12 A mozilla-M-C-error-code-trace-for-write-read.patch 13 A mozilla-M-C-negative-error-code-processing.patch 14 A mozilla-M-C-buffer-setup.patch 15 A mozilla-M-C-better-error-nsBufferedStreams.patch 16 A mozilla-M-C-NS_FillArray-short-read-issue.patch 17 A mozilla-M-C-cacheblock-short-read.patch 18 A mozilla-M-C-ReadPluginInfo-short-read.patch 19 A win32.patch 20 A trychooser.patch However, looking at the log in http://ftp.mozilla.org/pub/mozilla.org/thunderbird/try-builds/[email protected]/try-comm-central-linux-debug/try-comm-central-linux-debug-bm76-try1-build0.txt.gz and believing the order in which the following commands are executed reflects the order in which the hg commands are executed sequentially Executing command: ['hg', 'import', '-R', 'mozilla', '-m', 'local patch from /builds/slave/tb-try-c-cen-lx-d-000000000000/build/mozilla-M-C-NS_FillArray-short-read-issue.patch', '--no-commit', '--force', '/builds/slave/tb-try-c-cen-lx-d-000000000000/build/mozilla-M-C-NS_FillArray-short-read-issue.patch'] Executing command: ['hg', 'import', '-R', 'mozilla', '-m', 'local patch from /builds/slave/tb-try-c-cen-lx-d-000000000000/build/mozilla-M-C-ReadPluginInfo-short-read.patch', '--no-commit', '--force', '/builds/slave/tb-try-c-cen-lx-d-000000000000/build/mozilla-M-C-ReadPluginInfo-short-read.patch'] ... The following is the order in which M-C patches being applied on tryserver. (I culled the patch's filename portion from these "Executing command:" linesand removing the prfix /builds/slave/tb-try-c-cen-lx-d-000000000000/build/) mozilla-M-C-NS_FillArray-short-read-issue.patch', mozilla-M-C-ReadPluginInfo-short-read.patch', mozilla-M-C-add-error-check-to-read.patch', mozilla-M-C-better-error-nsBufferedStreams.patch', mozilla-M-C-buffer-setup.patch', mozilla-M-C-cacheblock-short-read.patch', mozilla-M-C-do-not-call-FcFini-because-it-crashes-due-to-failure-to-release.patch', mozilla-M-C-error-code-trace-for-write-read.patch', mozilla-M-C-intl-icu-debug.patch', mozilla-M-C-negative-error-code-processing.patch', Ouch. Obviously that the patch files are applied in the order of its FILENAME'S SORTING ORDER.Upper case comes before lowercase, too. My memory is a little bit rusty, but there was no requirement for the name of the patches such that the alphanumerical sorting of the mozilla-*.patch filename must be in the order that the patches are applied. Hmm... TIA _______________________________________________ dev-builds mailing list [email protected] https://lists.mozilla.org/listinfo/dev-builds
