Closed Bug 70363 Opened 24 years ago Closed 23 years ago

Inconsistent Build ID on nightly build!

Categories

(SeaMonkey :: Build Config, defect, P2)

x86
Linux
defect

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.
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
Closed: 23 years ago
Resolution: --- → FIXED
verifying.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.