Linux net installer exceeds 100% when downloading talkback component

VERIFIED FIXED in mozilla1.0

Status

SeaMonkey
Build Config
P2
normal
VERIFIED FIXED
17 years ago
14 years ago

People

(Reporter: Ian Clarke, Assigned: dveditz)

Tracking

Trunk
mozilla1.0
x86
Linux

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

17 years ago
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.

Updated

17 years ago
QA Contact: gemal → gbush

Comment 1

17 years ago
over to Samir.
Assignee: ssu → sgehani

Comment 2

17 years ago
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

Comment 10

17 years ago
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

Comment 12

17 years ago
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

Comment 13

17 years ago
retargeting, accepting.
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.4 → mozilla0.9.5

Comment 14

17 years ago
Bug 81242 is basically identical. Which one is to be duped?
*** Bug 81242 has been marked as a duplicate of this bug. ***

Comment 16

17 years ago
not blocking 0.9.5, moving to 0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6

Comment 17

17 years ago
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.

Comment 18

17 years ago
in bug 105732 this seems to cause a crash
*** Bug 83478 has been marked as a duplicate of this bug. ***

Comment 20

17 years ago
Duplicate bug 83478 had 6 duplicates and 1 vote by itself, this might be worth
noting as it qualifies this bug as a mostfreq.

Comment 21

17 years ago
*** Bug 107285 has been marked as a duplicate of this bug. ***

Comment 22

17 years ago
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)

Comment 23

17 years ago
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).

Comment 24

17 years ago
9.7
Target Milestone: mozilla0.9.6 → mozilla0.9.7

Comment 25

17 years ago
Lately this is happening even without talkback selected, but only 5 or 6 times.
Perhaps a rounding error, or other slight miscalculation.

Comment 26

17 years ago
*** Bug 111197 has been marked as a duplicate of this bug. ***

Comment 27

17 years ago
*** Bug 111768 has been marked as a duplicate of this bug. ***

Comment 28

17 years ago
leaf - this should be simple and has several dups - lets get this in 0.9.8
Target Milestone: mozilla0.9.7 → mozilla0.9.8

Comment 29

17 years ago
*** Bug 115079 has been marked as a duplicate of this bug. ***

Comment 30

17 years ago
it would be nice to get this fixed for 1.0.
Target Milestone: mozilla0.9.8 → mozilla1.0

Comment 31

17 years ago
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.

Comment 32

17 years ago
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?

Comment 33

17 years ago
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.

Comment 34

17 years ago
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 

Comment 35

17 years ago
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).

Comment 36

16 years ago
Created attachment 75251 [details]
Screenshot showing the download dialog where the downloaded size is larger than expected size

The errors starts to be printed on the console as soon as the downloaded size
is larger than the total size to be downloaded.

Comment 37

16 years ago
Created attachment 75252 [details]
Screenshot showing the progress dialog a bit later.

Comment 38

16 years ago
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

Comment 39

16 years ago
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: nsbeta1 → nsbeta1-
*** Bug 135488 has been marked as a duplicate of this bug. ***

Comment 41

16 years ago
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
(Assignee)

Comment 42

16 years ago
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
(Assignee)

Comment 43

16 years ago
Created attachment 78135 [details] [diff] [review]
Hardcode real sizes from current builds (plus 1%)

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 44

16 years ago
Comment on attachment 78135 [details] [diff] [review]
Hardcode real sizes from current builds (plus 1%)

r=syd
Attachment #78135 - Flags: review+

Comment 45

16 years ago
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.

Comment 46

16 years ago
Okay, I should read the manpage for ls better next time. Sorry for that.
(Assignee)

Comment 47

16 years ago
*** Bug 137832 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 48

16 years ago
*** Bug 139223 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 49

16 years ago
*** Bug 141161 has been marked as a duplicate of this bug. ***

Comment 50

16 years ago
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.
(Assignee)

Comment 51

16 years ago
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

Comment 52

16 years ago
verified on branch build 2002052909
Keywords: fixed1.0.0 → verified1.0.0

Comment 53

16 years ago
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.
(Assignee)

Comment 54

16 years ago
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+

Comment 55

16 years ago
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 56

16 years ago
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+
(Assignee)

Comment 57

16 years ago
Checked into 1.1
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 58

16 years ago
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.