195897 - MacOS nightly bad build, disk image doesn't mount

Status: VERIFIED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Tracy Walker [:tracy]]

seen on Mac mozilla/commercial build 2003-03-04-03-trunk

-download the .dmg.gz file
-unzip the .gz file
-double click the resulting .dmg

shortly, the disc copy dialog comes up, then the disc copy fails with: 
:"...-MachO.dmg" failed to mount due to error 95. (no mountable file systems)

Comment 1

[Alec Flett]

that sounds like a corrupted build, and should go to the build system folks..
probably just needs a respin

over to jj for now

Comment 2

[Frankie]

Just for the record,
ftp://ftp.mozilla.org/pub/mozilla/nightly/latest-trunk/mozilla-mac-MachO.dmg.gz
has a file size of 996 bytes. Latest-1.3 is slightly bigger, weighing in at 41kB.

On the bright side, I'm glad you're working so hard to eliminate bloat. :)

Comment 3

[kysmith0 (gone)]

Just kicked off a respin, we'll see how it goes. 

Comment 4

[J.J. Enser]

for some reason, toady's nightly build is apparently failing in js:

Creating ../../../dist/include/js
../../../config/nsinstall -L /src/seamonkey/trunk/mozilla/js/src/fdlibm -m 644
fdlibm.h ../../../dist/include/js
/usr/bin/perl -I../../../config ../../../config/build-list.pl
../../../dist/include/js/.headerlist fdlibm.h
Creating .deps
gcc -DMDCPUCFG= -DXP_UNIX -DXP_MACOSX -DNO_X11 -O2 -g -DOSTYPE=\"Darwin6.0\"
-DOSARCH=\"Darwin\" -DOJI -DEXPORT_JS_API  -DJS_USE_SAFE_ARENA
-I/src/seamonkey/trunk/mozilla/dist/include/nspr  -o jscpucfg jscpucfg.c
./jscpucfg > jsautocfg.tmp
mv jsautocfg.tmp jsautocfg.h
../../config/nsinstall -L /src/seamonkey/trunk/mozilla/js/src -m 644 jsautocfg.h
js.msg jsapi.h jsarray.h jsarena.h jsatom.h jsbit.h jsbool.h jsclist.h jscntxt.h
jscompat.h jsconfig.h jsdate.h jsdbgapi.h jsdhash.h jsemit.h jsfun.h jsgc.h
jshash.h jsinterp.h jslock.h jslong.h jsmath.h jsnum.h jsobj.h jsopcode.tbl
jsopcode.h jsosdep.h jsotypes.h jsparse.h jsprf.h jsprvtd.h jspubtd.h jsregexp.h
jsscan.h jsscope.h jsscript.h jsstr.h jstypes.h jsutil.h jsxdrapi.h jsstddef.h
../../dist/include/js
/usr/bin/perl -I../../config ../../config/build-list.pl
../../dist/include/js/.headerlist jsautocfg.h js.msg jsapi.h jsarray.h jsarena.h
jsatom.h jsbit.h jsbool.h jsclist.h jscntxt.h jscompat.h jsconfig.h jsdate.h
jsdbgapi.h jsdhash.h jsemit.h jsfun.h jsgc.h jshash.h jsinterp.h jslock.h
jslong.h jsmath.h jsnum.h jsobj.h jsopcode.tbl jsopcode.h jsosdep.h jsotypes.h
jsparse.h jsprf.h jsprvtd.h jspubtd.h jsregexp.h jsscan.h jsscope.h jsscript.h
jsstr.h jstypes.h jsutil.h jsxdrapi.h jsstddef.h
make[3]: *** No rule to make target `export'.  Stop.
make[2]: *** [tier_2] Error 2
make[1]: *** [default] Error 2
make: *** [build] Error 2

Full log at: http://rocknroll/users/jj/publish/mach-0-030304.log

We need to figure out why nigthly builds have this problem while tinderbox
builds don't.

Comment 5

[J.J. Enser]

make by hand in /mozilla/js and mozilla/js/src don't generate any error on the
nightly build machine, so I'm not so sure the problem is in js after all.

the nightly automation is using
make -f client.mk checkout
and then
make -f client-mk build

while tinderbox uses just 1 call: make -f client.mk

Another difference in nightly build is the use of this option:
--enable-optimize=-O2 -g

Can any of these differences explain the error?
cls?
anybody?
This bug is keeping the tree closed, so we need all the help we can get on this.

Comment 6

[hacker formerly known as [e-mail]]

You should use 'make -w' to build on OS X so that you get the "Entering
directory" & "Leaving directory" spew.  The problem (that I can't reproduce)
looks like it occurs in the directory that gets processed after js/src which
would be lib/mac/MoreFiles .   Based upon the error, it looks like the Makefile
wasn't generated correctly (probably a zero-byte file).  None of the make
commands or configure options should make a difference there.

Comment 7

[Simon Fraser [no longer active]]

So is something bad here:
http://lxr.mozilla.org/seamonkey/source/allmakefiles.sh#896

Comment 8

[Simon Fraser [no longer active]]

the build machine is running Darwin 6.0, and everything else is running 6.3 or
later. Maybe that's it?

Comment 9

[hacker formerly known as [e-mail]]

ARGH!  Yeah, that's me.  The MACOSX=1 got removed when I landed the X-on-X
changes.  

Comment 10

[hacker formerly known as [e-mail]]

Attachment: fix

Comment 11

[Simon Fraser [no longer active]]

So why the **** didn't tinderbox break?

Comment 12

[Simon Fraser [no longer active]]

Fix checked in.

Comment 13

[Chris Casciano]

File:
ftp://ftp.mozilla.org/pub/mozilla/nightly/latest-trunk/mozilla-mac-MachO.dmg.gz

is currerntly 1KB w/ timestamp of:
 3/5/03  	7:00:00 AM

shouldn't this fix have been in by then?

Comment 14

[Tracy Walker [:tracy]]

this is still broken with 2003-03-05-03-trunk builds (commercial and mozilla)

reopening

Comment 15

[Tracy Walker [:tracy]]

the original build from this morning was broken. (perhaps for some other reason)
 However, jj, setup a back up build, which ran successfully.  Granrose just
pushed those bits.  

remarking fixed 

Comment 16

[Tracy Walker [:tracy]]

verified with repushed bits at 2003-03-05-03-trunk

Comment 17

[Simon Fraser [no longer active]]

Can we please fix the build process so that we don't push bad disk images when
the build fails? Maybe some error checking?

Comment 18

[J.J. Enser]

yes, yes... the nightly build script is still a work in progress, and that's on
top of the list.

I have a couple of crucial things (including error handling) that I want to add
to this script, but after that, I'll probably start looking at adding mach-O
build support to the "other" seamonkey-build script, the one Client Release has
been using for years to build unix. It's robust and does everything we need + more.
What's missing is the OSX disk image packaging.

Thanks again to bryner for the initial work - that helped me a lot!

Comment 19

[Chris Casciano]

ftp://ftp.mozilla.org/pub/mozilla/nightly/latest-trunk/mozilla-mac-MachO.dmg.gz

is currently
1 KB  	3/6/03  	6:54:00 AM

Shouldn't this bug be reopened and stay open untill we go a day without the
script pushing out a bad build? Or, if the script error checking is a different
bug, then shouldn't this be reopened and stay open until we don't have 1kb builds?

Comment 20

[J.J. Enser]

do not reopen this bug. Adding error handling to the build automation and
preventing bad builds to be pushed will happen in bug 195435