Closed Bug 554232 Opened 10 years ago Closed 10 years ago

Add/Remove Programms shows 3.6.2pre for 3.6 Release L10n Builds

Categories

(Firefox :: General, defect)

3.6 Branch
x86
Windows 7
defect
Not set

Tracking

()

RESOLVED WONTFIX

People

(Reporter: cbook, Unassigned)

Details

Attachments

(1 file)

Attached image screenshot
On Windows the Add/Remove Programm Overview show for Firefox 3.6.2 the entry 3.6.2pre instead of the expected 3.6.2

En-US Builds are good, L10n Builds like L10n show this problem, see screenshot
23:22 < nthomas> the working theory is that we did not cleanup properly between build2 and build3, which left '-DAPP_VERSION=3.6.2pre' and '-DMOZ_APP_VERSION=3.6.2pre' when building localised files, like the installer


The question is: what's affected. We know add/remove programs is, and we know that the AUS pings are not.

If it's just the uninstall dialogs, then I don't think this is a big deal. If it's more, then it's a big deal.
Right now it looks like there's no other effect. We've checked:

 - update pings
 - blocklist pings
 - search codes
 - add on compatibility
 - add on compatibility override
 - crash stat versions
 - installer text
Also tested:

 - install
 - uninstall
I suspect that the APP_VERSION is picked up my the nsis code, and is then written to the registry or something like that. But that's really just me stabbin' in really dark places.

I'm hopeful that Rob actually knows where windows picks up the version, and where the build gets that from.
We decided to ship without this, but nthomas has said he'd track down the originating cause and follow up here.
To state comments #1-3 in another way, the correct en-US build was repacked but somehow the app version was 3.6.2pre when building the nsis installer bits.

Notes:
Looks like a clobber did get set at 15/Mar/2010:15:53:37 -0700, there's a POST by Armen in the http logs then.

In build 2001, the first l10n job for build3, which started at Mar 16 10:52 on win32-slave01, we have the checking_clobber_times step:
 Checking clobber URL: http://build.mozilla...
 win32_repack:Our last clobber date:  2010-03-15 15:53:35
 win32_repack:Server clobber date:    2010-03-15 15:53:35
to confirm the clobber was set. IIRC this indicates an earlier job performed the clobber.

The get_enUS_src step:
 pulling from http://hg.mozilla.org/releases/mozilla-1.9.2
 searching for changes
 no changes found
 0 files updated, 0 files merged, 0 files removed, 0 files unresolved
which is bad because it should be pulling the whole repo (first repack job after clobber). Later  inspection on that slave (which would have done several l10n jobs in the meantime) finds that mozilla-1.9.2 is on revision 827a6883442f, aka FIREFOX_3_6_2_BUILD2.

More confirmation of the lack of clobber in the configure step:
 loading cache ./config.cache
is the first line after echoing the mozconfig. 

So the clobber was set but hadn't worked for some reason, resulting in these definitions in config/autoconf.mk
  FIREFOX_VERSION = 3.6.2pre
  MOZ_APP_VERSION = 3.6.2pre
Those and browser/version/config.txt are the only references to 3.6.2pre I can find in win32-slave01:/e/builds/moz2_slave/win32_repack/build.

I'll try to track down the build that attempted the clobber, and check what happened on the other slaves (it's possible only some locales are affected given 8 slaves are allocated to this work).
Mystery solved:
* the l10n jobs for build2 ran between Mar 15 14:48 and 17:05 PDT
* the clobber was set at 15:53 PDT

The clobber should have been set _after_ all the build2 jobs had finished, rather than in the middle.

All locales are affected by this problem.
Nick and Armen: what's the effect of the problem, in terms of where the 3.6.2pre string gets picked up as well as any other sideeffects?
More specifically: since the clobber was set _before_ the build2 jobs had finished, what was the effect? What files were not cleared that should have been? What environment variables were not reset that should have been?

Also: was a clobber not run between builds 2 and 3? I thought that build2 had the bad numbering issue for en-US and l10n, and that was the cause of build3.

Until we know the effect of the misplaced clobber, we can't really work through the impact to the shipped bits.
Clarification, at least as far as I got it:

The clobber came in after the en-US build 2, but before the last l10n builds2 were done, so it clobbered en-US build 3 and some of the middle l10n builds 2. But not l10n builds 3.

So much for why we had a cached version number with 3.6.2pre in the build dirs.

As for this bug, I suspect that the actual nsis packaging process picks up the version number and puts it somewhere. I don't know jack about that though, so I'm hoping for Rob to enlighten us on where that would spread and how to verify that.
(In reply to comment #10)
> Clarification, at least as far as I got it:
> 
> The clobber came in after the en-US build 2, but before the last l10n builds2
> were done, so it clobbered en-US build 3 and some of the middle l10n builds 2.
> But not l10n builds 3.
> 
That is correct.

(In reply to comment #9)
> More specifically: since the clobber was set _before_ the build2 jobs had
> finished, what was the effect? What files were not cleared that should have
> been? What environment variables were not reset that should have been?
> 
I will look into this in the slave machine.


(In reply to comment #10)
> I don't know jack about that though, so
> I'm hoping for Rob to enlighten us on where that would spread and how to verify
> that.
Rob's enlightenment will be sweet.
version.txt is read here
http://mxr.mozilla.org/mozilla-central/source/browser/installer/windows/Makefile.in#52

APP_VERSION now contains the version

The version gets set here as provided by @APP_VERSION@
http://mxr.mozilla.org/mozilla-central/source/browser/installer/windows/nsis/defines.nsi.in#2

At this point AppVersion contains the version

The display name for the uninstall is set here using AppVersion
http://mxr.mozilla.org/mozilla-central/source/browser/installer/windows/nsis/shared.nsh#368

AppVersion is used in
http://mxr.mozilla.org/mozilla-central/search?string=AppVersion&find=\.nsi%24&findi=\.xul%24&filter=^[^\0]*%24&hitlimit=&tree=mozilla-central

http://mxr.mozilla.org/mozilla-central/search?string=AppVersion&find=\.nsh%24&findi=\.xul%24&filter=^[^\0]*%24&hitlimit=&tree=mozilla-central

I'll review the code to see if there are any areas that are of concern.

One good thing is that the nsis code was written to handle upgrades unlike the xpinstall installer code in that it doesn't require knowledge of the previous version it is upgrading from. So, when Firefox gets an app update it will update the values or remove the old values and then add the new values.
The uninstall survey will have 3.6.2pre in the url - minor
The file version and product version for the helper.exe file will be 3.6.2pre - minor

The remainder are registry keys that shouldn't cause a problem.
(In reply to comment #9)
> More specifically: since the clobber was set _before_ the build2 jobs had
> finished, what was the effect? What files were not cleared that should have
> been? What environment variables were not reset that should have been?
>
This is what happened (the following code will help me explain it).

if [ -d mozilla-1.9.2 ];
then hg -R mozilla-1.9.2 pull -r default ;
else hg clone http://hg.mozilla.org/releases/mozilla-1.9.2 mozilla-1.9.2 ;
fi
hg -R mozilla-1.9.2 update -r FIREFOX_3_6_2_RELEASE

Since mozilla-1.9.2 existed (the clobber was done at the wrong time and therefore it existed) we pulled but the working did not get updated and therefore it really was in FIREFOX_BUILD2/FIREFOX_3_6_2_RELEASE rather than FIREFOX_BUILD3/FIREFOX_3_6_2_RELEASE.

I filed bug 554439 to fix this specific problem.

I think this is not a valid "Firefox/General" since the wrong source code was being used when repackaging but something that needs to be fixed in "Release Engineering" side.
Armen: please move the bug to whereever you believe it belongs.

Rob: thanks for chasing it down. Much appreciated.
This specific problem won't be hit since we will fix it on bug 554439.

Nothing to be done on the Firefox side.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.