From Bugzilla Helper: User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.17 i686) BuildID: 2001022705/2001022711 I downloaded the most recently nightly build, and found that the build ID reported is inconsistent. This makes it difficult to file consistent bug reports. Reproducible: Always Steps to Reproduce: 1. Run "./mozilla --version" and note Build ID number in output. 2. Run "./mozilla" and note Build ID number in browser title bar. 3. Compare build ID numbers. Actual Results: The build ID numbers are different. Expected Results: The build ID numbers should be identical.
I'm seeing this sort of thing too.
Assignee: asa → cls
Status: UNCONFIRMED → NEW
Component: Browser-General → Build Config
Ever confirmed: true
QA Contact: doronr → granrose
ooh, this is a beaut. I tried today's mozilla 2001-02-27-13 linux trunk build. --version reports 2001-02-27-05 titlebar reports 2001-02-27-14 dated directory reports 2001-02-27-13 This is bad. We really really should have one buildid for all three. This may be a duplicate of an existing bug, but the --version behavior is new to me. cc'ing leaf. I'm going to set m0.9 just because this has been biting us for so long it would be good to be finally done with it.
Target Milestone: --- → mozilla0.9
i didn't even know we *had* a --version option! my bugs are all for windows inconsistencies... so this is probably not a dupe.
Yay...more fallout from bug 26798. The funny thing is that we do have a single variable that we use to set the date (with the exception of layout's gbdate.pl). --version uses NS_BUILD_ID which is set in config/nsBuildID.h . Whenever we build in config/ with BUILD_OFFICIAL set, the build_number will *always* be updated (if it will be different) causing nsBuildID.h to always be updated. What it looks like is that nsBuildID.h is being regenerated after xpfe/bootstrap/nsAppRunner.cpp is built. And I bet this is caused by the PSM builds. The psm build traverses config/ but not xpfe/.
Priority: -- → P2
are we any closer to a fix for this?
Well, part of this problem will resolve itself when we switch to building psm2 as part of the build (still working on the win32 nss autoconf issues). Then the titlebar & datedir will be sync'd. I'll have to dig a bit to figure out the --version problem.
Jon, I'm not sure why your test showed --version being so far off but I downloaded today's gcc295 nightly and --version, the window title and the directory all matched up. Since we're still doing the separate pass for building psm2, I think there's still a chance it may be off in the future. It may depend upon the build machine. (gcc295 was done by myotonic).
I'd be more interested in seeing what's happening with the 8am builds since I suspect part of the problem is due to depend builds and since the 4/5am and 8pm builds are full clobbers I wouldn't expect to see the problem there.
With the 2001-04-19-08 mozilla-i686 nightly, I'm seeing all of the version numbers being synced up as well. So we can either mark this fixed or slide it down to 0.9.1. We are still waiting for psm/nss to be intergrated into the normal build (post 0.9) which would avoid the second build pass. Right now, the datestamp offset appears to be contigent upon how long the 8am depend build takes and whether the subsequent psm depend build is also done in the 8 o'clock hour.
Target Milestone: mozilla0.9 → mozilla0.9.1
I concur and don't see this problem with the most recent 2001-05-08-14 linux builds either. user agent buildid, titlebar buildid, --version, and date dir all show the same date/time. resolving.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.