fixed. thanks! please verify this after the web site finishes updating in 30 minutes or so.
The test needs to be if (builddate && builddate != "00000000")
*** Bug 184782 has been marked as a duplicate of this bug. ***
*** Bug 184783 has been marked as a duplicate of this bug. ***
The nagger test still needs a slight change as per comment #2
-> fixed again
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 email@example.com). 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.
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.