Closed Bug 397842 Opened 12 years ago Closed 12 years ago
Cannot produce win32 en-US and l10n Firefox builds from the same tinderbox
The bug here is that the current l10n release and nightly branch tinderboxes use Cygwin with /cygdrive mounted "textmode", which causes all files to be created with DOS-style line endings. The default for Cygwin is "binmode"; on the en-US side Tinderbox client explicitly calls unix2dos.exe to convert the files it cares about (README and license). This has it's own problems, specifically that these files are modified in the checkout, so conflicts happen if anyone checks in a change to these files before a Depend build. I think the real fix here is going to be doing any necessary conversion on the files after the build but before the packaging, and we should do this for both l10n and en-US. I think this is probably more appropriate for the build system than for Tinderbox. In the interim, I've worked up a patch to bootstrap so that it can change textmode/binmode as-needed (leaving the default to binmode after l10n Repack is done).
Comment on attachment 282630 [details] [diff] [review] bootstrap workaround for l10n EOL problems Sorry for the delay Rob. This looks fine to me, except that it's a little confusing at first what's happening. I guess that's because it's non-POSIX-y, but also that it isn't documented at "man mount" (in the sense that using -c applies the other flags to all the automatic drive mounts under /cygdrive). This form might be slightly clearer, ['-b', '-sc', '/cygdrive' ] as well as emphasizing the binary/text mode.
Attachment #282630 - Flags: review?(nrthomas) → review+
Bootstrap/Step/Repack.pm Checking in Bootstrap/Step/Build.pm; /cvsroot/mozilla/tools/release/Bootstrap/Step/Build.pm,v <-- Build.pm new revision: 1.18; previous revision: 1.17 done Checking in Bootstrap/Step/Repack.pm; /cvsroot/mozilla/tools/release/Bootstrap/Step/Repack.pm,v <-- Repack.pm new revision: 1.17; previous revision: 1.16 done
Whiteboard: waiting on review and blocker → patch landed, waiting on blocker
This workaround works for bootstrap (just got a good test run from staging); going to close this one and fix the root problem in bug 351476.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
No longer depends on: 351476
Resolution: --- → FIXED
Whiteboard: patch landed, waiting on blocker
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.