Build 2000092106 reports itself as 2000091312



18 years ago
14 years ago


(Reporter: minter, Assigned: cls)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta3++])


(2 attachments)



18 years ago
I downloaded build 2000092106 from the nightly tree, but on the title bar it's
reporting itself as Build ID: 2000091312.

Comment 1

18 years ago
Confirmed on Linux.
Ever confirmed: true

Comment 2

18 years ago
This stuff is part of the build system, yes?
Assignee: asa → cls
Component: Browser-General → Build Config
QA Contact: doronr → granrose

Comment 3

18 years ago
cc: leaf

Comment 4

18 years ago
linux commercial build  2000-09-25-06-M18 reports itself as 2000-09-13-12
Installer build of 20000925xx reporting itself as Netscape 6, build 2000091312

Comment 6

18 years ago
Ok, figured out what was wrong at least.   The rule that was added
a couple of weeks ago disappeared during the latest jar packaging landing.
Severity: minor → major
Keywords: nsbeta3
Priority: P3 → P2

Comment 7

18 years ago
Chris: I don't see why that rule was needed. The contents of one of the 
generated files never changed (as far as I could tell) so I just folded it into 
the checked in file. (Which makefile was that again?)

Comment 8

18 years ago
Created attachment 15493 [details] [diff] [review]
Resurrect fix for build ids

Comment 9

18 years ago
The makefile is xpfe/browser/resources/locale/en-US/ . 
navigator.dtd.out gets created so that we aren't modifying files in the srcdir
and it only changes to update the build id.  The updating of the build id only
occurs if you set MOZILLA_OFFICIAL or BUILD_OFFICIAL.  I think we're going to
need to get this onto the branch as well.  

I needed to make a tweak to to make it handle files in the local
dir (as opposed to automatically tacking on the srcPath) but I haven't tested it
on windows.  

Comment 10

18 years ago
I can see why navigator.dtd needs to be generated (as it is), but I can't see 
why needs to be. Why?

Comment 11

18 years ago
Currently, navigator.dtd is getting sucked in from the src tree by
xpfe/browser/ .  We need to replace that file with the generated one by
creating our own local or by calling by hand (which is what
we did initially).  We could check in our local file but then we'd have
to make sure that it was not triggered for the windows build which does not have
the extra .out step.

Comment 12

18 years ago
Again, it makes perfect sense that navigator.dtd.out is generated and inserted 
into the jar file as navigator.dtd. I just don't see why needs to be 
generated too. All it needs to say (as the one I checked in says) is:

+        locale/en-US/navigator/navigator.dtd    (navigator.dtd.out)

It's completely static, as far as I can tell.

Comment 13

18 years ago
I have no problem with checking in the local file instead of generating
it.  My concern is that if you name it '', you will trigger the chrome
magic under windows which does not have a navigator.dtd.out file.  

Comment 14

18 years ago
Created attachment 15506 [details] [diff] [review]
Use to update chrome.

Comment 15

18 years ago
Ok... I've now determined that I forgot to check in the that I made for 
that directory, otherwise I would have stumbled on the lack of 
navigator.dtd.out for Windows. It all makes sense now.

I like the idea of redefining the JAR_MANIFEST variable -- that seems pretty 
simple. What's the diff in for?

Comment 16

18 years ago
Getting the proper build number is very fundamental to customer support and 
feedback.  I'm putting this on the beta3++ radar, as we would really like this 
straight in PR3. 
Whiteboard: [nsbeta3++]

Comment 17

18 years ago
Hmm... since this is currently assigned to cls, I should clarify:
The beta3++ means that you have permiission to land the fix (after the 
superreview etc.) on the Netsacpe PR3 branch (so that this will be in PR3 and 
Netsacpe's RTM).
If you don't want to mess with that branch, then after you fix it on the trunk 
(hopefully RSN), then re-assign to someone in Netscape to make the landing.
We're hoping to finalize PR3 this week, and this fix is pretty critical to a PR3 

Comment 18

18 years ago
The diff to is to handle the objdir case.  In EnsureFileInDir()
around line 127, you were unconditionally prepending $srcPath to the file that
we are making sure exists.  Since navigator.dtd.out is a generated file, it will
never be in the srcdir so the test always fails.  The patch changes
to only prepend the $srcPath if the file does not exist in the current

Comment 19

18 years ago
*** Bug 54213 has been marked as a duplicate of this bug. ***

Comment 20

18 years ago on that second attachment

Comment 21

18 years ago
Supposedly this was committed to CVS, but i just re-built from CVS and I'm
getting a build ID of "00000000000" (didn't count the number of 0s) in the
titlebar.. Could this be because I only built the changed files, not rebuilt
from scratch, or is this not really fixed yet?

Comment 22

18 years ago
The fix has been checked into the trunk & the branch.  Marking fixed.

For non-official builds, the build id will always be set to 000000000 on unix
(and eventually on mac & win).  See bug 26798
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 23

18 years ago
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.