Closed Bug 21904 Opened 25 years ago Closed 25 years ago

Build ID is off by four months

Categories

(SeaMonkey :: Build Config, defect, P3)

x86
Linux

Tracking

(Not tracked)

VERIFIED INVALID

People

(Reporter: olaf, Assigned: granrosebugs)

Details

This is on a Linux scratch build updated from CVS and built on 1999-12-15. The Build ID field in the lower right corner shows "1999082316" which already got me a bug report rejected with a notice of "use a newer build, four months is too old" :-( Apparently this field is defined in mozilla/xpfe/browser/resources/locale/en-US/navigator.dtd, which has a file date of 1999-12-11, CVS release 1.41. Sev=major because this makes bugzilla reports useless.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
sorry I can't be of better help, but this can't be right. The build id is built automatically as part of the build process, and it working fine for all the builds I know of here in Mountain View. are you doing a "gmake -f client.mk pull_and_build_all" from your mozilla directory? It sounds like maybe you're not building the whole tree, or perhaps your tree doesn't have all the right files. If you're still having problems, post your build environment and problems to netscape.public.mozilla.builds on news.mozilla.org and someone will be able to help you out.
the build # only gets updated if you have MOZILLA_OFFICIAL set. For the daily builds and the milestone builds, we set this env variable so that the build numbers are updated. if you build locally on your tree, the build number won't get dynamically generated. the reason why we don't do this for debug is that it produces extra diffs in a development tree, even if the file didn't change. also, developers kept checking in changed build numbers in the dtd file, when there were no other changes.
verified
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.