Closed
Bug 53559
Opened 24 years ago
Closed 24 years ago
Build 2000092106 reports itself as 2000091312
Categories
(SeaMonkey :: Build Config, defect, P2)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: minter, Assigned: cls)
References
Details
(Whiteboard: [nsbeta3++])
Attachments
(2 files)
1.40 KB,
patch
|
Details | Diff | Splinter Review | |
1.10 KB,
patch
|
Details | Diff | Splinter Review |
I downloaded build 2000092106 from the nightly tree, but on the title bar it's
reporting itself as Build ID: 2000091312.
Comment 2•24 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•24 years ago
|
||
cc: leaf
Comment 4•24 years ago
|
||
linux commercial build 2000-09-25-06-M18 reports itself as 2000-09-13-12
Comment 5•24 years ago
|
||
Installer build of 20000925xx reporting itself as Netscape 6, build 2000091312
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•24 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?)
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•24 years ago
|
||
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?
Assignee | ||
Comment 11•24 years ago
|
||
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•24 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 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.
Assignee | ||
Comment 13•24 years ago
|
||
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.
Assignee | ||
Comment 14•24 years ago
|
||
Comment 15•24 years ago
|
||
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•24 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•24 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
ship.
Thanks,
Jim
Assignee | ||
Comment 18•24 years ago
|
||
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•24 years ago
|
||
*** Bug 54213 has been marked as a duplicate of this bug. ***
Comment 20•24 years ago
|
||
r=disttsc@bart.nl on that second attachment
Comment 21•24 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?
Assignee | ||
Comment 22•24 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
Status: ASSIGNED → RESOLVED
Closed: 24 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
•