Closed
Bug 52065
Opened 24 years ago
Closed 24 years ago
jar packaging broken on unix
Categories
(SeaMonkey :: Build Config, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: paul, Assigned: jag+mozbugs)
References
Details
Attachments
(7 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.15 i686; en-US; m18) Gecko/20000910
BuildID: 20000910??
Mozilla no longer displays the build number in the title.
The about: Mozilla page doesn't give the number to the same resolution (ie it
misses out the hours).
This makes commenting on bugs with a degree of certainty difficult. Eg. I have a
bug that has a comment saying it appears to be fixed in CVS 2000091009, but I
still see it in my build, but have no idea whether it was created before or
after 2000091009.
Reproducible: Always
Steps to Reproduce:
1.Fire up Mozilla
2.Curse the fact that you can't update a bug report because you don't know what
your build is.
Updated•24 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 1•24 years ago
|
||
This seems to be because the jar packaging and the current way the build number
is put into the source for unixen don't play nice together. I think I've got a
solution to fix this, I'll try and catch a build person on irc tomorrow to
discuss it.
Component -> build config, reassigning to default owner.
Assignee: asa → cls
Component: Browser-General → Build Config
QA Contact: doronr → granrose
For now, I'm applying this inline patch to
xpfe/browser/resources/locale/en-US/Makefile.in . Reassigning bug to dprice so
he can work with jag to properly fix the build number / jar package problem
before jar packaging lands.
Index: xpfe/browser/resources/locale/en-US/Makefile.in
===================================================================
RCS file: /cvsroot/mozilla/xpfe/browser/resources/locale/en-US/Makefile.in,v
retrieving revision 1.18
diff -u -r1.18 Makefile.in
--- Makefile.in 2000/09/09 22:54:07 1.18
+++ Makefile.in 2000/09/11 01:56:36
@@ -47,7 +47,7 @@
# GARBAGE += navigator.dtd.out
GARBAGE_DIRS += navigator.dtd.out
-ifneq ($(MOZ_ENABLE_JAR_PACKAGING),)
+ifeq ($(MOZ_ENABLE_JAR_PACKAGING),)
navigator.dtd.out: navigator.dtd $(DEPTH)/config/build_number
cp $(srcdir)/navigator.dtd $@
$(PERL) $(topsrcdir)/config/aboutime.pl $@ $(DEPTH)/config/build_number
Assignee: cls → dprice
Comment 5•24 years ago
|
||
Doh my logic was backward. I'm adding this to my radar. What is the process
that's used to generate the build number for unixen?
Increasing severity to blocker since we seem to not have anyone's attention and
unix boxes are starting to break due to various problems with the make-jars.pl
script. In no particular order,
No error checking for system calls . We silently fail if zip isn't installed.
Doesn't work for objdir builds, which affects a good number of developers and
most of our ports tinderboxes.
xpcom/base/jar.mn appears to be wrong. There is no
global/locale/xpcom.properties but there is xpcom.properties.
No checks for the perl modules we use. ActiveState & perl 5.005_03 from RH 6.x
may come with File::Stat but according to our build page, the minimum revision
of perl requires is perl5 (which to me reads, perl 5.000). Which means that the
minimum set of modules are the ones that come from perl 5.000. If you want to
be more specific than that you'd better state it.
The usage of getopt & while(<>) breaks under perl 5.005_03 which comes with RH
6.2. And that is without using 'use strict'.
Severity: normal → blocker
Status: NEW → ASSIGNED
Keywords: nsbeta3
Priority: P3 → P1
Summary: Mozilla no longer displays build number → jar packaging broken on unix
Comment 10•24 years ago
|
||
I just tested the changes to configure.in, and guess what:
bernoulli{ah} /opt/gnu/bin/perl5.00503 -V:apiversion
apiversion='5.005';
bernoulli{ah} /opt/gnu/bin/perl5.6.0 -V:apiversion
apiversion='UNKNOWN';
The Config.pm for 5.005 has a
apiversion='5.005'
and the Config.pm for 5.6.0 has
pm_apiversion='5.005'
xs_apiversion='5.6.0'
The comment may say 5.005 or greater, but it sure doesn't check. Good that the
tree is closed.
Axel
Comment 11•24 years ago
|
||
Jar packaging is temporarily disabled on unix, until we can first land bug
45937 and fix up the unix installer.
Comment 12•24 years ago
|
||
Comment 13•24 years ago
|
||
Comment 14•24 years ago
|
||
Ok, all of the unix jar changes are in now with the exception of the jar.mn
fixes. I created a new make-jars-unix.pl instead taking the chance of subtly
breaking windows. Someone with more time than I currently have can merge the
two if they'd like.
Comment 15•24 years ago
|
||
Comment 16•24 years ago
|
||
Comment 17•24 years ago
|
||
I need a r= on the trivial patch to bump up our minimum revision of perl to
5.004.
Marking actual bug as fixed as jar packaging does work on linux now.
Assignee | ||
Comment 18•24 years ago
|
||
Looks okay, but why do we require 5.004 now?
Also, reopen this bug, or file a new one?
Comment 19•24 years ago
|
||
5.004 because that's the earliest distribution of perl that comes with the
File:: modules that we use in the make-jars.pl script. In theory, someone could
add those modules by hand and still run the script on 5.000, but I'd rather not
deal with that hassle for the general case.
I'd rather not file a new bug just to have the one-liner fix go in. This is the
most relevant bug for the change to be attached .
Comment 20•24 years ago
|
||
Assignee | ||
Comment 21•24 years ago
|
||
Well, alternatively you could write a configure test which checks for the
existence of File:: modules, but I guess 5.004 will do. If people complain, we
can still go that route. r=jag on the 5.004 patch.
Also r=jag on the PERL environment check.
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•