57419 - linux trunk netscape 6 builds broken

Status: VERIFIED FIXED

(SeaMonkey :: Build Config, defect, P3)

Description

[Jon Granrose]

I'm reporting this in bugzilla because cls doesn't have a bugscape account
(can't get past the firewall).

This appears to be a regression from bug 26798.  This morning's trunk linux
commercial builds are failing setting the build date:

gmake[1]: Entering directory `/builds/client/linux22/seamonkey/ns/config'
Copying files from /builds/client/linux22/seamonkey/mozilla/dist
rm -f ../build/build_number
/usr/bin/perl /builds/client/linux22/seamonkey/mozilla/config/aboutime.pl
../xpfe/browser/resources/locale/en-US/navigator.dtd ../build/build_number
Can't locate mozBDate.pm in @INC (@INC contains:
/usr/lib/perl5/5.00503/i386-linux /usr/lib/perl5/5.00503
/usr/lib/perl5/site_perl/5.005/i386-linux /usr/lib/perl5/site_perl/5.005 .) at
/builds/client/linux22/seamonkey/mozilla/config/aboutime.pl line 3.
BEGIN failed--compilation aborted at
/builds/client/linux22/seamonkey/mozilla/config/aboutime.pl line 3.
gmake[1]: *** [../build/build_number] Error 2
gmake[1]: *** Deleting file `../build/build_number'
gmake[1]: Leaving directory `/builds/client/linux22/seamonkey/ns/config'
gmake: *** [export] Error 2

I'm looking into it.  This is a smoketest blocker for the netscape 6 tree since
we have no linux trunk builds.

Comment 1

[Jon Granrose]

I copied the mozBDate.pm file it was looking for from mozilla/config to
ns/config, and the build completed, but that is a temporary workaround.  This
problem will hit us again at 8pm tonight.

cls - is that the best fix and should we just check that file into the ns tree,
or is there a more elegant fix we can put into place by 8pm tonight?

Comment 2

[cls]

Attachment: Add ../mozilla/config to perl INCS (via -I) when calling bdate or aboutime

Comment 3

[cls]

Sorry about that.  I completely missed those calls to aboutime.pl (or I would've
fixed them too).  The proper fix is to make sure that the perl include path
contains the mozilla/config directory.  This patch takes care of the problem on
linux commercial and should fix the windows side as well (still waiting for that
build to finish).

Comment 4

[Jon Granrose]

looks good to me, r=granrose.

Comment 5

[cls]

Oh, disregard the babble about the windows build.  The comm tree has its own
copies of aboutime.pl & bdate.pl.

Comment 6

[cls]

The fix is in.

Comment 7

[Jon Granrose]

same problem, new error.  I've changed the commercial tinderbox script to set
BUILD_OFFICIAL so we'll catch these problems more quickly in the future.  From
the commercial tb log:

gmake[1]: Entering directory
`/builds/tinderbox/SeaMonkey/Linux_2.2.14-5.0smp_depend/ns/config'
Copying files from
/builds/tinderbox/SeaMonkey/Linux_2.2.14-5.0smp_depend/mozilla//dist
rm -f ../build/build_number
/tools/ns/bin/perl5
-I/builds/tinderbox/SeaMonkey/Linux_2.2.14-5.0smp_depend/mozilla/config
/builds/tinderbox/SeaMonkey/Linux_2.2.14-5.0smp_depend/mozilla/config/aboutime.pl
../xpfe/browser/resources/locale/en-US/navigator.dtd ../build/build_number
../xpfe/browser/resources/locale/en-US/navigator.dtd: No such file or directory
gmake[1]: *** [../build/build_number] Error 2 gmake[1]: *** Deleting file
`../build/build_number' gmake[1]: Leaving directory
`/builds/tinderbox/SeaMonkey/Linux_2.2.14-5.0smp_depend/ns/config' gmake: ***
[export] Error 2

Comment 8

[cls]

Ok, I've removed that line entirely.  That file no longer exists and hasn't for
about 6 months.  I didn't hit the problem in my local build because I had a zero
length navigator.dtd for some reason.  Removing the aboutime.pl call in
config/Makefile.in fixes this particular bustage.

However, I ran into another problem that may have been silently plaguing us for
awhile as well.  Whenever I do a commercial depend build with MOZILLA_OFFICIAL &
BUILD_OFFICIAL set, the build id does not get updated.  At first glance, it
appears as though the copy-dist.pl script (which copies mozilla/dist into
ns/dist) only copies files that do not exist.  I see no timestamp checking in
the script.

Comment 9

[Jon Granrose]

copy-dist.pl got hacked by dr a month or two ago, so that probably didn't used
to be the problem.

Do you think the ns buildid should be the same as the mozilla buildid or should
it be possible to just hack ns, rebuild and have it generate a new buildid just
for ns?

Comment 10

[cls]

That's really a question for QA.  How do they match up mozilla builds &
commercial builds based upon a build id?  My gut says that they assume that both
trees were pulled and built at the same time so they must have the same build id.

Ideally, I think we'd have a build id for each tree. This way you would be able
to make changes to the commercial tree without needing to update and rebuild
your underlying mozilla tree.  Not sure how'd we represent that in the build id
or store it in some retrievable manner (another build.dtd?) .

Comment 11

[Jon Granrose]

I agree.  Ideally, the buildid would be the date the tree was pulled, but we
don't have time to hack that right now.  I like the idea of having the mozilla
and ns buildids be the same, so how about hacking ns to just grab the mozilla
buildid instead?

Comment 12

[cls]

Attachment: Updated copy-dist.pl to check timestamps

Comment 13

[Jon Granrose]

looks good to me.  r=granrose.

Comment 14

[Simon Fraser [no longer active]]

cc self. Resolution will affect the mac commercial build scripts.

Comment 15

[cls]

The copy-dist patch has been checked in.  The changes to the commercial mac
build scripts were checked in last week.

Comment 16

[Jon Granrose]

verified.

I've also updated the commercial tinderboxen to build with BUILD_OFFICIAL so we
will catch problems like this on the tb in the future.