I downloaded build 2000092106 from the nightly tree, but on the title bar it's reporting itself as Build ID: 2000091312.
Confirmed on Linux.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This stuff is part of the build system, yes?
Assignee: asa → cls
Component: Browser-General → Build Config
QA Contact: doronr → granrose
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
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.
Severity: minor → major
Status: NEW → ASSIGNED
Priority: P3 → P2
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?)
Created attachment 15493 [details] [diff] [review] Resurrect local-jar.mn/navigator.dtd fix for build ids
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.
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?
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.
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.
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.
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?
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.
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
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.
*** Bug 54213 has been marked as a duplicate of this bug. ***
firstname.lastname@example.org on that second attachment
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?
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
Last Resolved: 18 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.