112631 - Installation fails in download with error message :Too many download errors...

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect)

Description

[Tracy Walker [:tracy]]

seen on windows 98 commercial build 2001-11-29-06-trunk

-attempt to install the build with the stub or blob(I chose recommended without 
quicklaunch)

the installation process begins fine, but soon an error message pops up saying 
"there are too many dowload errors...."

note: this mornings corrseponding linux and mac os9 builds install fine.

Comment 1

[Matthias Versen [:Matti]]

related to bug 112312 ?
see http://bugzilla.mozilla.org/show_bug.cgi?id=112312#c6

Comment 2

[Tracy Walker [:tracy]]

cc'ing Shuresh based on his comment of installation failure in bug 112312

Comment 3

[Nicolás Lichtmaier]

This alsa happens on Linux.

Comment 4

[Marc Attinasi]

I added two files to the pacakger files - could this be causing any problems? I
doubt it is, because Linux and Mac ar OK, but I'm CC'in myself in case there is
potential for problems from my changes.

Comment 5

[prass]

DP, does this belong to you? is this a dupe of 
http://bugzilla.mozilla.org/show_bug.cgi?id=112312?

Comment 6

[Suresh Duddi (gone)]

I have backed out my changes to libjar - buffer and malloc reduction (10%
improvement of startup performance on windows) until I prove that this isnt
causing the problem.

We are guessing it is related until I prove otherwise.
http://bugzilla.mozilla.org/show_bug.cgi?id=112312

Maybe I should take this bug. syd feel free to take it back. I need help with
building the installer in debug though :-(

Comment 7

[Suresh Duddi (gone)]

Sorry back to syd. My changes are not there anymore as of 6:48am 11/29. This is
something else.

http://bonsai.mozilla.org/cvsquery.cgi?module=MozillaTinderboxAll&branch=HEAD&cvsroot=/cvsroot&date=explicit&mindate=1007045280&maxdate=1007045940&who=dp%25netscape.com

Comment 8

[Asko Tontti]

Might this have something to do with bug 102574 (enable document inspector)?

(Linux packages are missing inspector.xpi so complete install doesn't work
as expected.)

Comment 9

[Asa Dotzler [:asa]]

This belongs to hewitt. The install works fine if you select custom and uncheck
the document inspector. 

Comment 10

[prass]

Re-assigning to Hewitt 

Comment 11

[Asa Dotzler [:asa]]

the workaround is to not install the inspector. I think we can lower this from
blocker to critical. It doesn't prevent further testing or development.

Comment 12

[Tracy Walker [:tracy]]

Suresh,  the build i tested (2001-11-29-06-trunk)  began building at 3:00am. The 
process most likely had finished pulling well before 6:48.

Asa...how does one deselct the document inspecto?  I don't see it either options 
list during the installation custom setup dialogues.

Comment 13

[prass]

Lowering to critical since there is a workaround

Comment 14

[Asa Dotzler [:asa]]

hmm, maybe twalker is experiencing a different problem then me. I see the
inspector in the list of xpi's in the custom install panel. Perhaps it's not in
commercial
builds. Strange that it would fix the install failure for me to remove it and
it's not even a choice for you. 

Maybe this should stay a blocker until we get it figured out.

Comment 15

[Suresh Duddi (gone)]

And if this a bug from the 3am build, I would say we need to retest with the 8am
builds as I backed out my change at 6:48am (hoping the 8am build will catch it).
BTW whats this 3am build anyway.

Comment 16

[Daniel Veditz [:dveditz]]

Why isn't the buildid the *pull* timestamp instead of the build time? wouldn't
that make more sense?  Not only would we have a better idea exactly what went
into the build--which the confusion in this bug shows would be a good thing--it
would also have the advantage of lining up the buildID's across platforms for
equivalent builds rather than letting slow machines artificially skew the date.

Comment 17

[prass]

looks like dp's backout fixed this

Comment 18

[Tracy Walker [:tracy]]

the very latest windows build (2001-11-29-09-trunk)  installs fine.  marking 
fixed.

dveditz...ask granrose about the build ID

Comment 19

[Jon Granrose]

short answer: because we've always done it this way, and to change it would open
up huge heaps of confusion.  In this particular case, it wouldn't make a
difference since the actual buildid would be 2001112904 (the directory is named
-06 because that's when it was created when the mozilla build was delivered). 
So all you would know is that the mozilla build finished sometime in the 6am
hour, and the pull started at 3am.  you wouldn't know if your backout was picked
up or not if you checked in sometime in that period, and you wouldn't know no
matter if the buildid was the start of the pull time or the start of the build time.

The early morning builds are there because when they work, testing them allows
us to open the tree early when they pass.  If they have problems like they did
today, then we look at the 8am builds to see if the problem still exists.  We
can stop doing the 3am builds if you don't mind the tree going back to staying
closed til noon every day just waiting for the builds to finish, and
smoketesting not being done til 2pm and the tree opening on average around 4pm.

Comment 20

[Daniel Veditz [:dveditz]]

I don't get it, don't we pull by -D <timestamp> ? We appear to on tinderbox
(except mac?), and it sure would be nice to know definitely that if it's a Xam
build a (x-1):59 checkin made it and a x:01 checkin didn't. Doesn't matter what
X is as long as we can figure it out somehow.

Comment 21

[Grace Bush]

verified on build 2001113003