Closed Bug 84492 Opened 23 years ago Closed 22 years ago

Linux net installer exceeds 100% when downloading talkback component

Categories

(SeaMonkey :: Build Config, defect, P2)

x86
Linux
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.0

People

(Reporter: ian, Assigned: dveditz)

References

Details

Attachments

(3 files)

During the installation process, after a number of packages have been installed,
the progress bar reaches 100% before installation is complete.  The installer
then starts to print:

Gtk-CRITICAL **: file gtkprogress.c: line 518 (gtk_progress_set_percentage):
assertion `percentage >= 0 && percentage <= 1.0' failed.

It looks like the total download size is failing to account for some of the
packages being installed.
QA Contact: gemal → gbush
over to Samir.
Assignee: ssu → sgehani
Reassigning to me.
Assignee: sgehani → syd
*** Bug 84609 has been marked as a duplicate of this bug. ***
confirming based on the dupe...
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 84638 has been marked as a duplicate of this bug. ***
*** Bug 92609 has been marked as a duplicate of this bug. ***
I just installed trunk build 2001072821 and I do not see this problem any more.
Not sure why but the 2001072821 build did not have talkback (or at least I could
not find it).

The 2001072906 build has talkback again and now I'm getting those errors once
more.  Is this part of the problem?
Aha!  Found the problem here.

From config.ini (extracted from the net installer tar.gz):

[Component5]
Description Short=Quality Feedback Agent
; *** LOCALIZE ME BABY ***
Description Long=Tool for reporting software crashes to Netscape
Archive=talkback.xpi
Install Size=33
Archive Size=1

Timeless told me that talkback is not posted right away because "it takes time
to strip the binaries."  The tar.gz is posted with Archive Size=1.  This is fine
if you don't download the talkback component, or if it is not on the server to
download (as was the case when I posted my last comment).

However, when you do download the talkback.xpi, it is definitely more than 1K
and thus it causes the progress bar to exceed 100% since it is downloading more
than expected.

leaf: is this yours?
Component: Installer → Build Config
Summary: Progress bar is exceeding 100% → Linux net installer exceeds 100% when downloading talkback component
it's my problem, insofar as the unix automation doesn't regenerate the
config.ini file for the stub installer when it replaces the dummy talkback
file... are you using the net installer, or the full installer?
It's all in the net installer as far as I know.  I'm assigning this to you for
now, leaf.
Assignee: syd → leaf
the talkback.xpi file size has to be hard coded into the config.ini file for all
platforms for mozilla.  I thought it already was, but it seems I'm mistaken.
Priority: -- → P2
Target Milestone: --- → mozilla0.9.4
retargeting, accepting.
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Bug 81242 is basically identical. Which one is to be duped?
*** Bug 81242 has been marked as a duplicate of this bug. ***
not blocking 0.9.5, moving to 0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6
The warning is coming up a few times even when I deselect QFA. Not 100s though,
like when QFA is installed, just 2 or 3. So something else is still slightly off.
in bug 105732 this seems to cause a crash
*** Bug 83478 has been marked as a duplicate of this bug. ***
Duplicate bug 83478 had 6 duplicates and 1 vote by itself, this might be worth
noting as it qualifies this bug as a mostfreq.
*** Bug 107285 has been marked as a duplicate of this bug. ***
Just tried to install mozilla the very first time, didn't get past about 300k of
xpcom.xpi before the installer died. It said:
./mozilla-installer: line 55:  1586 Speicherzugriffsfehler 
./mozilla-installer-bin --sync $@

Gtk-CRITICAL **: file gtkprogress.c: line 518 (gtk_progress_set_percentage):
assertion `percentage >= 0 && percentage <= 1.0' failed.

"Speicherzugriffsfehler" could be translated as memory access error

When I restarted the installer, it happened again. 

My system: Debian 2.2r4 (with junkbuster installed, but no proxy selected for
the mozilla install)
I just re-tried installation, with a freshly downloaded installer & a clean
directory, this time it did work. I got a lot of messages like:
Gtk-CRITICAL **: file gtkprogress.c: line 518 (gtk_progress_set_percentage):
assertion `percentage >= 0 && percentage <= 1.0' failed.

but the installer did continue all the way through. I suspect last time it got
somehow irritated because I had closed the internet connection during the
download (to switch to another provider).
9.7
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Lately this is happening even without talkback selected, but only 5 or 6 times.
Perhaps a rounding error, or other slight miscalculation.
*** Bug 111197 has been marked as a duplicate of this bug. ***
*** Bug 111768 has been marked as a duplicate of this bug. ***
leaf - this should be simple and has several dups - lets get this in 0.9.8
Target Milestone: mozilla0.9.7 → mozilla0.9.8
*** Bug 115079 has been marked as a duplicate of this bug. ***
it would be nice to get this fixed for 1.0.
Target Milestone: mozilla0.9.8 → mozilla1.0
This should be pretty simple to fix. I bet it has to do with the talkback.xpi
sizes (compressed and expanded) being wrong in the config.ini file.
Suprsingly this WORKS FOR ME in build 2002012821, RH7.2. I have chosen Typycial
installation and (for the first time ever) I have seen no warnings on exceeding
this 100 limit. Is this a common experience now?
Unfortunately, no. I got the following errors with 2002-01-28-21 on Linux during
a custom install (Navigator, MailNews, PSM and Talkback):

Gtk-CRITICAL **: file gtkprogress.c: line 518 (gtk_progress_set_percentage):
assertion `percentage >= 0 && percentage <= 1.0' failed.

Gtk-CRITICAL **: file gtkprogress.c: line 518 (gtk_progress_set_percentage):
assertion `percentage >= 0 && percentage <= 1.0' failed.
I saw it on one of 3 installs with the 1/28 nightly so it hasn't completely gone
Install was custom with Navigator, Mail/News and Talkback selected 
A follow-up to my comment 33: the same build installs without warnings if I
choose a typical install (which is what  andrzej was doing too).
The errors starts to be printed on the console as soon as the downloaded size
is larger than the total size to be downloaded.
Nominating because this makes us look like morons.

Leaf, can we just put a "guaranteed to be too big" size in there if we don't
know the real size?  No one will notice if the progress bar goes to 85 then the
dialog disappears (they'll just think the last 15% was really fast), while it's
impossible not to notice three hundred lines of error messages printed to stdout
on every install.
Keywords: mozilla1.0, nsbeta1
nsbeta1- since this doesn't impact Netscape bits, only mozilla bits.

leaf is swamped working on the win32 gmake system.  cc'ing asasaki in case he
has time after finishing his versioning changes.
Keywords: nsbeta1nsbeta1-
*** Bug 135488 has been marked as a duplicate of this bug. ***
Below is a table comparing the size we specify in config.ini with the real size
of the .xpi's. As can be seen, talkback.xpi is the big miss: it's specified as
being 1k in config.ini while it really is 812k! The rest of the xpi's need minor
adjustments as well.

Can we please have this fixed ASAP?

config.ini                     real size:
----------                     ----------
Archive=browser.xpi
Archive Size=7474              7488

config.ini                     real size:
----------                     ----------
Archive=mail.xpi
Archive Size=1832              1836

config.ini                     real size:
----------                     ----------
Archive=psm.xpi
Archive Size=754               760

config.ini                     real size:
----------                     ----------
Archive=chatzilla.xpi
Archive Size=102               108                 

config.ini                     real size:
----------                     ----------
Archive=talkback.xpi
Archive Size=1                 812

config.ini                     real size:
----------                     ----------
Archive=defleus.xpi
Archive Size=7                 8

config.ini                     real size:
----------                     ----------
Archive=langenus.xpi
Archive Size=558               564

config.ini                     real size:
----------                     ----------
Archive=regus.xpi
Archive Size=33                36

config.ini                     real size:
----------                     ----------
Archive=venkman.xpi
Archive Size=151               156

config.ini                     real size:
----------                     ----------
Archive=inspector.xpi
Archive Size=212               216
Don't forget that a K is 1024 bytes, not 1000. I get exactly the sizes in the
config.ini when I look at
ftp://ftp.mozilla.org/pub/mozilla/nightly/2002-04-07-06-trunk/linux-xpi/

If you look at the above directory you can see the problem: talkback.xpi is
created some time after the rest of them (since it's a donation from the
Netscape commercial build). This has already been mentioned in this bug.

I'm tired of the whining, taking the bug
Assignee: leaf → dveditz
Status: ASSIGNED → NEW
Hardcoding the sizes I get from a Netscape commercial build plus about 1% for
growth. Today's Netscape build has installed size 1940 and archive size 806.

The mozilla windows installer apparently already takes this approach. I've
updated the install size to current values, the archive size is still a few K
higher than the actual value.
Comment on attachment 78135 [details] [diff] [review]
Hardcode real sizes from current builds (plus 1%)

r=syd
Attachment #78135 - Flags: review+
dveditz, the "real size" I specified is the size that "ls -ks" tells me for the
.xpi files and the -k option is:

-k, --kilobytes
      like --block-size=1024

I don't know how mozilla calculates the file size, but I actually trust ls more
in this case.

This bug also shows up when you don't intall talkback, although fewer errors are
printed, so to me it makes sense that the other sizes are somewhat wrong too.
Okay, I should read the manpage for ls better next time. Sorry for that.
*** Bug 137832 has been marked as a duplicate of this bug. ***
*** Bug 139223 has been marked as a duplicate of this bug. ***
*** Bug 141161 has been marked as a duplicate of this bug. ***
I just downloaded and did a ``complete'' install of
  Mozilla 1.0 Release Candidate 1
  Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417
from
 
ftp://archive.progeny.com/mozilla/releases/mozilla1.0rc1/mozilla-i686-pc-linux-gnu-1.0rc1-installer.tar.gz
.
I see the bug is still here. The progress indicator gives a number that's well
over 100 percent, and I get over 50 copies of the error message
  ``Gtk-CRITICAL **: file gtkprogress.c: line 518 (gtk_progress_set_percentage):
assertion `percentage >= 0 && percentage <= 1.0' failed.''
.
I agree with Akkana. if we can't automate getting the correct numbers, the next
best thing is to hardcode numbers that are 15 % too big.
This is fixed on the branch, not yet on the trunk. Or at least the bulk of this
attributable to talkback is fixed. Now that that's out of the way maybe we'll
find smaller problems hiding.
Keywords: fixed1.0.0
verified on branch build 2002052909
I am afraid that I probably see the same bug in
mozilla 1.1 beta installer.

While trying to install the
talkback-enabled network installer (the one
that fetches xpi files via network),
it spews out the following  messages.

The installation seemed to work, though.
(I am using 1.1b thus installed)

But it sure will be nice to wipe out this bug since
the uncertainty of installation success gives very
bad feeling to new users.

Messages I found out after leaving the console
for a while.

 ... many repetitions of the following lines.
Gtk-CRITICAL **: file gtkprogress.c: line 518 (gtk_progress_set_percentage):
assertion `percentage >= 0 && percentage <= 1.0' failed.

Gtk-CRITICAL **: file gtkprogress.c: line 518 (gtk_progress_set_percentage):
assertion `percentage >= 0 && percentage <= 1.0' failed.

Gtk-CRITICAL **: file gtkprogress.c: line 518 (gtk_progress_set_percentage):
assertion `percentage >= 0 && percentage <= 1.0' failed.
Warning: MOZILLA_FIVE_HOME not set.
duron:/home/ishikawa/mozilla-installer#

I don't know what MOZILLA_FIVE_HOME not set WARNING is.
But again, this may leave a very uncomfortable feeling
to a new user.
Comment on attachment 78135 [details] [diff] [review]
Hardcode real sizes from current builds (plus 1%)

This patch got sr= as part of bug 125106. It was never checked in because it
was wrapped up in that big scary fix that I'm waiting for 1.2a for, but this
part should probably go in by itself.
Attachment #78135 - Flags: superreview+
If this has reviews, why not check it in now and make 1.1 look good instead of
waiting for 1.2a and making 1.1 look stupid.  This bug is more than a year old
now, very visible and the fix is trivial ...
Keywords: mozilla1.1
Comment on attachment 78135 [details] [diff] [review]
Hardcode real sizes from current builds (plus 1%)

a=asa (on behalf of drivers) for checkin to 1.1
Attachment #78135 - Flags: approval+
Checked into 1.1
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
verified on build 2002080902-1.1
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: