I attempted a tryserver calendar build and win32 is failing (see URL field for log). The problem is, its finding the wrong "install" binary and is then trying to install vim. checking for a BSD compatible install... /d/mozilla-build/vim/vim72/install -c ... for file in Microsoft.VC80.CRT.manifest msvcm80.dll msvcp80.dll msvcr80.dll ; do \ install --preserve-timestamps "/d/msvs8/VC/redist/x86/Microsoft.VC80.CRT"/$file ../../dist/bin ; \ done This program sets up the installation of Vim 7.2 Inspecting system... ERROR: failed to rename vim.exe to vim.exx: No error Press Enter to continue ...

This is a known issue with MozillaBuild package, see Bug 506020. The proposed solution/workaround is to remove install.exe from the vim folder.

(In reply to comment #1) > This is a known issue with MozillaBuild package, see Bug 506020. > The proposed solution/workaround is to remove install.exe from the vim folder. see also bug 506020 comment #11.

From what I can tell, to me this is looking more like a SeaMonkey/Calendar build config issue than a try server issue. I've looked at logs from a failed SeaMonkey run (comment 3), a successful Thunderbird run, and even a Firefox run on the MoCo try server. Looking at the environment variables both SeaMonkey & Thunderbird builds are set up the same. If I look through what configure output is doing I see: checking for a BSD compatible install... /d/mozilla-build/vim/vim72/install -c That is the same for all three builds I looked at. A bit more digging shows that the failed SeaMonkey build is trying to do some stuff in mozilla/build/win32, whereas Thunderbird & Firefox don't. make[6]: Entering directory `/e/buildbot/sendchange-win32-hg/mozilla/objdir/mozilla/build/win32' mkdir -p ../../dist/bin install --preserve-timestamps "/d/msvs8/VC/redist/x86/Microsoft.VC80.CRT"/Microsoft.VC80.CRT.manifest "/d/msvs8/VC/redist/x86/Microsoft.VC80.CRT"/msvcm80.dll "/d/msvs8/VC/redist/x86/Microsoft.VC80.CRT"/msvcp80.dll "/d/msvs8/VC/redist/x86/Microsoft.VC80.CRT"/msvcr80.dll ../../dist/bin This program sets up the installation of Vim 7.2 Inspecting system... ERROR: failed to rename vim.exe to vim.exx: No error Press Enter to continue Looking at the Makefile.in, it seems to be an issue with building with VC 8... Looking at both Thunderbird & Firefox makefiles they are both building with --enable-jemalloc and no other VC options or anything. Looking at SeaMonkey it has the following in the mozconfig being used: #Windows specific mk_add_options AUTOCONF=/local/bin/autoconf-2.13 export MOZ_DEBUG_SYMBOLS=1 WIN32_REDIST_DIR=/d/msvs8/VC/redist/x86/Microsoft.VC80.CRT Looking at the current mozconfigs for SeaMonkey this doesn't match: http://hg.mozilla.org/build/buildbot-configs/file/d4ee88bf54cc/seamonkey/win32/comm-central-trunk/nightly/mozconfig http://hg.mozilla.org/build/buildbot-configs/file/d4ee88bf54cc/seamonkey/win32/comm-1.9.1/nightly/mozconfig Therefore I'm guessing that there may be two bugs here: 1) Mozconfigs for SeaMonkey and Calendar are out of date. I'll co-ordinate with gozer on Monday to figure out and update the mozconfigs so that they reflect current builds. 2) There is some kind of issue with the current build setup when using WIN32_REDIST_DIR and/or the VC 8 stuff. This sounds like bug 506020, but fixing item 1 will work around this for try server.

Taking so I remember to talk to gozer about this.

You have WIN32_REDIST_DIR set because you're not --enable-jemalloc. Firefox builds don't have to use that, because they do use jemalloc.

I think the issue could also be fixed by changing: http://hg.mozilla.org/mozilla-central/file/3048d03980e7/build/win32/Makefile.in#l88 To use $(SYSINSTALL) or $(NSINSTALL) rather than calling the install binary from the $(PATH).

As noted, calendar has this problem too. See for example: http://tinderbox.mozilla.org/showlog.cgi?log=ThunderbirdTry/1260353518.1260354946.17039.gz

(In reply to comment #7) > You have WIN32_REDIST_DIR set because you're not --enable-jemalloc. Firefox > builds don't have to use that, because they do use jemalloc. Not sure why the tryserver isn't using --enable-jemalloc, as all our normal SeaMonkey builds do. Perhaps gozer needs to update something there. (In reply to comment #8) > I think the issue could also be fixed by changing: > > http://hg.mozilla.org/mozilla-central/file/3048d03980e7/build/win32/Makefile.in#l88 > > To use $(SYSINSTALL) or $(NSINSTALL) rather than calling the install binary > from the $(PATH). I think that's perfectly right, but probably another bug should be filed for it. An additional reason to correct it this way is that then a pymake build can potentially optimize this to use a no-new-process python version of install.

(In reply to comment #10) > (In reply to comment #7) > > You have WIN32_REDIST_DIR set because you're not --enable-jemalloc. Firefox > > builds don't have to use that, because they do use jemalloc. > > Not sure why the tryserver isn't using --enable-jemalloc, as all our normal > SeaMonkey builds do. Perhaps gozer needs to update something there. As I said at the end of my long comment 5, I'll sort out the mozconfigs for Calendar & SeaMonkey on Monday with gozer. > (In reply to comment #8) > > I think the issue could also be fixed by changing: > > > > http://hg.mozilla.org/mozilla-central/file/3048d03980e7/build/win32/Makefile.in#l88 > > > > To use $(SYSINSTALL) or $(NSINSTALL) rather than calling the install binary > > from the $(PATH). > > I think that's perfectly right, but probably another bug should be filed for > it. Again, at the end of my long comment 5 (that'll teach me), I believe this is bug 506020.

(In reply to comment #11) > Again, at the end of my long comment 5 (that'll teach me), I believe this is > bug 506020. That bug actually didn't talk much about the right fix, which I believe to be in the Makefile.

We've updated the default mozconfigs now so that they are pretty much the same as the nightly build ones (e.g. SeaMonkey & Calendar will build static by default). I've done some whitespace only patch builds which all turned out ok (apart from SM Mac which was due to the builder falling over, but I believe it should be fine anyway). Therefore resolving this as fixed now.