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)
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
Assignee | ||
Comment 1•22 years ago
|
||
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
Reporter | ||
Comment 2•22 years ago
|
||
The test needs to be
if (builddate && builddate[1] != "00000000")
Reporter | ||
Comment 3•22 years ago
|
||
*** Bug 184782 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 4•22 years ago
|
||
*** Bug 184783 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 6•22 years ago
|
||
The nagger test still needs a slight change as per comment #2
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Reporter | ||
Comment 7•22 years ago
|
||
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.
Updated•22 years ago
|
Comment 8•22 years ago
|
||
-> fixed again
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 9•22 years ago
|
||
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 → ---
Reporter | ||
Comment 10•22 years ago
|
||
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?
Comment 11•22 years ago
|
||
> 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...
Comment 12•22 years ago
|
||
*** Bug 211358 has been marked as a duplicate of this bug. ***
Comment 13•22 years ago
|
||
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
Reporter | ||
Comment 14•22 years ago
|
||
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.
Comment 15•22 years ago
|
||
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 ago → 22 years ago
Resolution: --- → FIXED
Updated•17 years ago
|
Product: mozilla.org → Websites
Updated•12 years ago
|
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.
Description
•