53559 - Build 2000092106 reports itself as 2000091312

Status: VERIFIED FIXED

(SeaMonkey :: Build Config, defect, P2)

Description

[H. Wade Minter]

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

Comment 1

[Jeffrey Baker]

Confirmed on Linux.

Comment 2

[Jeffrey Baker]

This stuff is part of the build system, yes?

Comment 3

[Doron Rosenberg (IBM)]

cc: leaf

Comment 4

[Tracy Walker [:tracy]]

linux commercial build  2000-09-25-06-M18 reports itself as 2000-09-13-12

Comment 5

[Dameon D. Welch-Abernathy]

Installer build of 20000925xx reporting itself as Netscape 6, build 2000091312

Comment 6

[cls]

Ok, figured out what was wrong at least.   The local-jar.mn rule that was added
a couple of weeks ago disappeared during the latest jar packaging landing.

Comment 7

[Warren Harris]

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

[cls]

Attachment: Resurrect local-jar.mn/navigator.dtd fix for build ids

Comment 9

[cls]

The makefile is xpfe/browser/resources/locale/en-US/Makefile.in . 
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 make-jars.pl 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

[Warren Harris]

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

Comment 11

[cls]

Currently, navigator.dtd is getting sucked in from the src tree by
xpfe/browser/jar.mn .  We need to replace that file with the generated one by
creating our own local jar.mn or by calling make-jars.pl by hand (which is what
we did initially).  We could check in our local jar.mn 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

[Warren Harris]

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 jar.mn needs to be 
generated too. All it needs to say (as the one I checked in says) is:

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

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

Comment 13

[cls]

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

Comment 14

[cls]

Attachment: Use unix-jars.mn to update chrome.

Comment 15

[Warren Harris]

Ok... I've now determined that I forgot to check in the jar.mn 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 make-jars.pl for?

Comment 16

[Jim Roskind]

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. 

Comment 17

[Jim Roskind]

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 
ship.
Thanks,
Jim

Comment 18

[cls]

The diff to make-jars.pl 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 make-jars.pl
to only prepend the $srcPath if the file does not exist in the current
directory.

Comment 19

[R.K.Aa.]

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

Comment 20

[Peter "jag" Annema]

r=[e-mail] on that second attachment

Comment 21

[Ari Pollak]

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

[cls]

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

Comment 23

[Jon Granrose]

verified.