Closed Bug 83405 Opened 24 years ago Closed 21 years ago

gecko build date only occasionally updated

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.7beta

People

(Reporter: dmosedale, Unassigned)

References

Details

Attachments

(3 files, 5 obsolete files)

the hard way
1.31 KB, patch
benjamin
: review+
asa
: approval1.7+
Details | Diff | Splinter Review
Use ksh93 on Solaris
557 bytes, patch
cls
: review-
Details | Diff | Splinter Review
Fix for Tru64 Unix (OSF1)
477 bytes, patch
Details | Diff | Splinter Review
My development builds have been locked out of bugzilla for weeks because the last time I pulled an update to gbdate.pl, it was on May 14th, the day of the form corruption bug. (I just got around to tracking down that that was the actual problem now). Rather than do the hacky thing and hardcode my user-agent, I tweaked the build system to update gbdate.h whenever the output of gbdate.pl changes. I'll be attaching a patch. It does assume that "cmp" and "mv" exist and have certain semantics, but these are both POSIXy things, so I'm hoping this won't cause any problems.
why is this assigned to me? is it because i'm the last person to touch gbdate.pl?
Yeah, and because the real tangible effect is in the HTTP user-agent, and I figured you'd be the most likely to care about that. However, feel free to give it to whomever...
Ugh. There is at least one build-order issue with my patch; taking until I can sort it out.
OS: Linux → All
See bug 81344.
->dmose
Assignee: darin → dmose
Target Milestone: --- → Future
Attachment #36588 - Flags: needs-work+
This is still a problem, and it affects the build-id that is displayed in the about: page. This really should get fixed.
Isn't this a build bug?
This is actually a dupe of bug 37484. It's questionably a build bug. The build system generates the build id but the modules are responsible for how they use it. Unnecessarily relinking layout just to get an updated build id is of questionable use. However, if the library is being relinked anyway, then the build id should probably be updated too. Or just move the build date into a separate, smaller auxillary library or data file.
-> per cls.
Assignee: dmose → other
Component: Networking: HTTP → Layout
QA Contact: benc → ian
Attachment #128801 - Attachment is obsolete: true
Attached patch third time's a charm (obsolete) — — Splinter Review
Attachment #36588 - Attachment is obsolete: true
Attachment #128830 - Attachment is obsolete: true
Attachment #129057 - Flags: review?(bryner)
Attachment #129057 - Flags: review?(bryner) → review+
The patch was checked in a couple of months ago by timeless.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Target Milestone: Future → mozilla1.7beta
*** Bug 238478 has been marked as a duplicate of this bug. ***
Reopening. The patch causes a regression when rebuilding just the layout module as pointed out in bug 238478.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached patch the hard way — — Splinter Review
This patch manually compares the timestamps of SHARED_LIBRARY_LIBS against a timestamp file which is a dependency of gbdate.h. Just smile and nod.
Attachment #129057 - Attachment is obsolete: true
Attachment #145606 - Flags: review?(bsmedberg)
Comment on attachment 145606 [details] [diff] [review] the hard way smile and nod... I would prefer if this file did not have a dot-filename, gbdate.tstamp?
Attachment #145606 - Flags: review?(bsmedberg) → review+
Attachment #145606 - Flags: approval1.7?
Comment on attachment 145606 [details] [diff] [review] the hard way a=asa (on behalf of drivers) for checkin to 1.7
Attachment #145606 - Flags: approval1.7? → approval1.7+
The patch has been checked in with the gbdate.tstamp change.
Status: REOPENED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → FIXED
Regression on Solaris: gmake[4]: Entering directory `/files/dsk1/lsw/anlan/m7/mozilla/layout/build' /files/dsk1/lsw/anlan/m7/mozilla/config/nsinstall -R -m 644 nsLayoutCID.h ../../dist/include/layout /usr/local/bin/perl -I../../config ../../config/build-list.pl ../../dist/include/layout/.headerlist nsLayoutCID.h /bin/sh: test: unknown operator -nt gmake[4]: *** [gbdate.tstamp] Error 1 From 'man -s1 test': file1-nt file2 True, if file1 exists and is newer than file2. (Not available in sh.)
Attached patch use ksh on solaris (obsolete) — — Splinter Review
Use ksh on solaris. We should just require ksh universally for solaris as we do for OSF/1 in NSPR.
Chris Seawood wrote: > Use ksh on solaris. > We should just require ksh universally for solaris as we do for OSF/1 in NSPR. I would prefer to use /usr/dt/bin/dtksh on Solaris since this is a ksh93, /usr/bin/ksh is ksh88 with all it's poor sideeffects.
Attachment #145712 - Attachment is obsolete: true
Comment on attachment 145761 [details] [diff] [review] Use ksh93 on Solaris The patch switchs shells globally - I do not like any partial switches which may lead to further confusion. None or all. :) (and it will protect Mozilla from further issues, ksh93 is much more compatible to bash2 than Sun's hacked ksh88).
Attachment #145761 - Flags: review?(cls)
Comment on attachment 145761 [details] [diff] [review] Use ksh93 on Solaris My only concern with that change is that /usr/dt used to be an optional install (Motif/CDE stuff iirc). If we're worried about bash2 compatibility, we should just require bash2. ksh88 should be good enough.
Chris Seawood wrote: > My only concern with that change is that /usr/dt used to be an optional > install (Motif/CDE stuff iirc). 1. The Sun Gnome desktop depends on stuff in /usr/dt/ so it is NOT an optional installation. 2. The Mozilla build itself depends on files in /usr/dt (they're also soft-linked to /usr/lib and /usr/include but the real files reside in /usr/dt) 3. The Solaris patch checker uses /usr/dt/bin/dtksh as runtime requirement with r= from Sun staff.
Comment on attachment 145761 [details] [diff] [review] Use ksh93 on Solaris Since what you said doesn't apply to older versions of solaris and we have no requirements for ksh93, I'm giving it a minus.
Attachment #145761 - Flags: review?(cls) → review-
(In reply to comment #28) > (From update of attachment 145761 [details] [diff] [review]) > Since what you said doesn't apply to older versions of solaris I doubt Mozilla support Solaris 2.4 or 2.5.1, right ? AFAIK Mozilla only builds and runs on Solaris >= 2.6 and even support for 2.6 is fading off. > and we have no > requirements for ksh93 If more and more bash'ismn are used in the build system then ksh93 may become a requirement on Solaris. bash is no option since this is an unbundeled product and not supported by Sun.
For Tru64 Unix also, observed that the following error occurs in the directory mozilla/layout/build: /bin/sh: test: unknown operator -nt
Proposing the fix of using ksh in OSF1 to get the build right.
Comment on attachment 149321 [details] [diff] [review] Fix for Tru64 Unix (OSF1) Per http://www.mozilla.org/build/unix-details.html , OSF1 should be using ksh anyway. You should open a separate bug if you want that hardcoded.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: