Closed Bug 184770 Opened 22 years ago Closed 22 years ago

javascript build nagger incorrectly checks for "0000000000" instead of "00000000" for self-builds

Categories

(www.mozilla.org :: General, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: gl, Assigned: endico)

References

()

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021210 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021210 I'm self building Mozilla (svg, xft, gtk2) under Linux (RH 8). The Javascript nagger on http://www.mozilla.org/start/ has a conditional check for self-builds. It checks against a build date of "0000000000" (a string of 10 zeros). However, the build date retrieved from the user agent string following the string "Gecko" is only 8 characters long - as per the format of "%08d" in gbdate.pl which creates it. So the javascript script needs to be modified to check for "00000000" (8 zeros) to turn of the nag for self builds. More generally, I kind of wondered why the Gecko build date and the Mozilla build date can be independently set and use different formats (8 characters versus 10 characters). I've read the discussion in bug 131116 where some of this was addressed earlier ... gbdate.pl Reproducible: Always Steps to Reproduce: 1. MOZ_BUILD_DATE="0000000000" 2. build 3. start mozilla, get a (friendly) nag about upgrading
fixed. thanks! please verify this after the web site finishes updating in 30 minutes or so.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
The test needs to be if (builddate && builddate[1] != "00000000")
*** Bug 184782 has been marked as a duplicate of this bug. ***
*** Bug 184783 has been marked as a duplicate of this bug. ***
v
Status: RESOLVED → VERIFIED
The nagger test still needs a slight change as per comment #2
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
I dont get nagged anymore ... But now that I've had a deeper look into build IDs versus Gecko build dates (and there's been quite a bit of discussion in bugzilla) it seems that the self-build test will never work. That's because in the nagger script the builddate is extracted from the user-agent string, specifically the Gecko build date using the regular expression "/Gecko\/(\d+)/". The Gecko build date is set by gbdate.pl, is 8 characters (and from what I can tell in the CVS history has always been 8 characters) and is not set to all zeros (and again from the CVS history appears to have never been set to all zeros). On the other hand the ten digit build ID which is set by bdate.pl is set (by default) to "0000000000" (ten zeros) for self-builds. However, the build ID is not being used by the nagger script. I dont know whether the build ID is even accessible to a Javascript script, although I doubt it otherwise I think it would have been mentioned in relation to bugzilla automatically capturing it. So the upshot is that the test for self builds to avoid nagging still does not work. And I'm unclear as to whether it ever did. I now touch (Linux) gbdate.pl as part of building when I update from the CVS tree. That causes the Gecko build date to be updated and so I dont get nagged for that reason. I'm reopening bug 131116 which is where the self-build test originated.
Blocks: 193444, 197927
Blocks: 202867
-> fixed again
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
I dont believe the test for self-builds is fixed. Actually, after looking into it once more, I believe the test for self-builds is broken and should be removed ... The javascript nagger in http://www.mozilla.org/start/index.html tests for self-builds by looking for a build date of "00000000" (a date of 8 zeros). It gets this date from the the UA string - specifically the Gecko component, e.g., the build date in my current UA string Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030515 is "20030515" Previously the nagger was looking for a build date of "0000000000" (ten zeros), but was changed as per my original bug report. The 8 character Gecko date will never be set "00000000" by the build mechanism (gbdate.pl and Makefile) which creates it. When self-building (under Linux at least) this date will be set to the date of the first build after pulling the tree. gbdate.pl produces gbdate.h which contains the Gecko build date string which winds up in the UA string: #define PRODUCT_VERSION "20030515" gbdate.h is never updated by the build mechanism unless gbdate.pl is "touched" to make it newer than gbdate.h. This is due to the Makefile rule BUILD_DATE = gbdate.h ... $(BUILD_DATE): gbdate.pl $(RM) $@ $(PERL) $(srcdir)/gbdate.pl > $@ gbdate.pl is rarely updated in the cvs tree. Certainly gbdate.pl is not systematically updated to trigger the gbdate.h rule above. For self-builders the "build id" (a ten digit date+hour), as opposed to the Gecko build date, is set to "0000000000". It is the build id that is shown in the window title bar. However, the build id string is not available from the UA string. Maybe a javascript script can find it via the DOM, but that's not what it being done at present. So I think the original test for self builds as per bug 131116 didnt actually work, and that still doesnt. Reopening (I didnt close). Suggestions to follow.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
As per comment 9 I think the nagger test (an if statement) for self-builds which endeavours not to nag the self-build users should be removed as I dont believe e it works. Pleased to hear otherwise. But this bug is now really more about having "correct" Gecko build dates than about being nagged, although the two are closely related. By default, for self-builders the build mechanism does not update the Gecko build date which is what the update nagger looks at. There are mechanisms for updating the build date (see below). An issue is whether the Gecko build date should really be viewed as a Gecko pull-and-build date - a sort of version number - rather than a Gecko build date. This was discussed in bug 46488 comment 44. Some possibilities to fix nagging/having correct Gecko build date for self-builders: 0) Ignore. I did for ages. Self builder may wonder why they are being nagged (and then find the bug reports). In my case I knew I was synced and up-to-date with the tree but my Gecko build date was out by months when I originally submitted this bug. 1) Either (a) touch gbdate.pl to trigger gbdate.h update or (b) set MOZ_BUILD_DATE. This should probably only be done when part of Gecko is updated, but I dont know how to tell which files (only) are a part of Gecko. Will cause gbdate.h to be updated (desired) and probably trigger dependencies with resulting longer build times (faster computers though). Put documentation in how to build Mozilla (hmm, should check it isnt already there!). 2) Change Makefile to FORCE gbdate.h update for each build. This has the side effect of updating the Gecko build date when building but _not_ updating the tree (say when testing patches). I think this would be wrong, but it was discussed in bug 46488 comment 44 where it was regarded as "even stevens". 3) Arrange to have gbdate.pl "touched" in the cvs tree when parts of Gecko are updated by people who know. Not sure if cvs allows a forced update to an unchanged file in the tree (no change to gbdate.pl) with the intention of changing the last modified date so as to flow through to people syncing to the tree. 4) Introduce a string into gbdate.pl which is updated at appropriate points by maintainers. That will also trigger a gbdate.h update for self-builders. That means Gecko build dates become stepped/versioned. Others?
> But this bug is now really more about having "correct" Gecko build dates than > about being nagged, although the two are closely related. this bug is about the script on the mozilla.org/start page (hence the component of webmaster@mozilla.org). having correct build dates in self-builds would fix the problem from a different direction, but that's not what this bug is about. if we're going to fix it that way, that should be a different bug in the correct component (and this one could depend on it). I'd certainly agree with taking this bit of the script out, but it may be worth mentioning that the script doesn't work for normal nightly builds either (bug 197927), so it wouldn't actually work even once this issue is fixed...
*** Bug 211358 has been marked as a duplicate of this bug. ***
I had a feeling my bug was a dup of this, but a second opinion is always good. Changing OS to ALL as I'm getting this on Win XP. FWIW, I'm building on WIN32 using gcc and NOT MSVC.
OS: Linux → All
Discussion, design and implementation of a new nagger is going on in bug 209537. The incorrect test for self-builds, the topic of this bug, will be fixed by the all of the naggers under consideration there. When a new nagger lands this bug should be closed, and a new one should probably be opened about getting correct build dates for self-builds as per comment #10. It should also be put against the appropriate module as per comment #11. The new naggers will not have the broken checks for "0000000000", but they will still nag self-builders when their gecko build date goes over the nag limit (2 weeks). For the self-builders reading this, the new nagger will still nag you even when you have just pulled-and-built. That's because your gecko build date _is_ old. See comment #10 for approaches to update your gecko build date. I generally touch gbdate.pl.
New code for bug 209537 has landed. It no longer looks for "00000000"/tries to detect self-builds at all. Resolving per last comment.
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
Product: mozilla.org → Websites
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in before you can comment on or make changes to this bug.