52065 - jar packaging broken on unix

Status: VERIFIED FIXED

(SeaMonkey :: Build Config, defect, P1)

Description

[Paul McGarry]

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.

Comment 1

[Peter "jag" Annema]

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.

Comment 2

[cls]

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

Comment 3

[cls]

*** Bug 52064 has been marked as a duplicate of this bug. ***

Comment 4

[:deanis74]

*** Bug 52090 has been marked as a duplicate of this bug. ***

Comment 5

[dprice (gone)]

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?

Comment 6

[dprice (gone)]

assigning to [e-mail]

Comment 7

[cls]

Attachment: Tweaks to make jar packaging work for objdir builds

Comment 8

[cls]

Attachment: updated changes to avoid modifying the srcdir

Comment 9

[cls]

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'.  

Comment 10

[Axel Hecht]

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

[Warren Harris]

Jar packaging is temporarily disabled on unix, until we can first land bug 
45937 and fix up the unix installer.

Comment 12

[cls]

Attachment: Fixes for broken jar manifest files

Comment 13

[cls]

Attachment: Ignore previous patch. xmlterm's jar file was still out of whack. this fixes that

Comment 14

[cls]

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

[Axel Hecht]

Attachment: This fixes some capitals, needed for the overlay to be found (and the js)

Comment 16

[cls]

Attachment: Bumping minimum rev of perl to 5.004.

Comment 17

[cls]

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.

Comment 18

[Peter "jag" Annema]

Looks okay, but why do we require 5.004 now?
Also, reopen this bug, or file a new one?

Comment 19

[cls]

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

[cls]

Attachment: Check PERL env variable first when trying to find perl

Comment 21

[Peter "jag" Annema]

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.

Comment 22

[Jon Granrose]

verified.