Closed
Bug 70363
Opened 24 years ago
Closed 23 years ago
Inconsistent Build ID on nightly build!
Categories
(SeaMonkey :: Build Config, defect, P2)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9.1
People
(Reporter: deven, Assigned: cls)
Details
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.
Comment 1•24 years ago
|
||
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
Comment 2•24 years ago
|
||
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
Comment 3•24 years ago
|
||
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
Comment 5•23 years ago
|
||
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).
Comment 8•23 years ago
|
||
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
Comment 10•23 years ago
|
||
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
Closed: 23 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•