Closed Bug 308391 Opened 19 years ago Closed 19 years ago

Stub installer shows wrong download size

Categories

(SeaMonkey :: Installer, defect)

x86
Windows XP
defect
Not set
trivial

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: bugzilla, Unassigned)

References

Details

(Keywords: regression)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050910 SeaMonkey/1.0a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050910 SeaMonkey/1.0a

Using the stub installer for SeaMonkey Alpha RC1, the wrong download size is
shown. The installers shows 262KB for complete download and therefore the
percentage value is calculated wrong (goes up to over 4000%).

Reproducible: Always

Steps to Reproduce:
1. Use the stub installer
2. Watch the % value
Actual Results:  
Download size and percentage value are wrong

Expected Results:  
Use the correct download size of the XPI packages for calculation percentage value.
Version: unspecified → 1.8 Branch
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-seamonkey1.0b+
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b4) Gecko/20050910 SeaMonkey/1.0a]
(release) (W98SE)

Confirmed: 262 KB, and reduced by 1 for each un-selected XPI in Custom mode.

<install_status.log> still looks right:
{{
    Disk Space Info:
             Path: K:\
         Required: 27014KB
        Available: 91672KB
             Path: X:\
         Required: 27188KB
        Available: 267760KB
}}

U.I. issue only !?
Keywords: regression
Does anyone know when exactly this regressed?
is this bug really trunk-only?

To get a regression range, someone needs to grab old nightly builds from
ftp.mozilla.org and/or archive.mozilla.org if it goes back that far.
> is this bug really trunk-only?

err... "branch-only", I meant.
(In reply to comment #4)
> > is this bug really trunk-only?
> 
> err... "branch-only", I meant.

Yes, Branch-Only:
I believe I checked Trunk when I wrote comment 1;
anyway, I checked again "nightly/2005-10-12-06-trunk";
which does not have this bug.
(In reply to comment #1)
> Confirmed: 262 KB, and reduced by 1 for each un-selected XPI in Custom mode.

Except 'Quality feedback agent', which counts for 248 KB.

(In reply to comment #2)
> Does anyone know when exactly this regressed?

Oldest available Stub-I is 'nightly/contrib/2005-09-10-09-mozilla1.8/',
which already has this bug.

Who builds this 'contrib' file ?
Could he check this behaviour, and if possible try and build a Trunk Stub-I, in
case it could be related to the build environment rather than a SM (==
"tinderboxed") regression ??
(In reply to comment #6)
> Oldest available Stub-I is 'nightly/contrib/2005-09-10-09-mozilla1.8/',
> which already has this bug.

Well, this could actually be the SMv1.0a release file !?
Anyway, this is the only Stub-I from 2005-09-04-16-mozilla1.8 to
2005-10-12-09-mozilla1.8 :-/

It seems we're stuck until someone can build some other date Stub-I.
{{
Not this bug, but while I'm there:

*2005-09-26-22-mozilla-1.8 could be renamed 2005-09-26-22-mozilla1.8 !?

*latest-mozilla1.8 misses a Stub-I link ... even an "outdated" one as gtk1 or
mac currently have.
}}
Right, I don't think we were uploading stub installers until late in the game. 
But you can cripple the full installer (from an older date) into being a stub
installer.

The stub installer is a self-extracing archive.  It extracts itself to a
temporary directory (in C:\WINDOWS\TEMP or some such thing).

1. Copy the contents of that directory elsewhere.
2a. As a simpler first step, look at the file sizes as listed in config.ini. 
See if they are reasonable and match what is in the actual online directory:
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/contrib/2005-09-10-09-mozilla1.8/windows-xpi/
2b. Remove the xpi subdirectory.
3. Edit the config.ini (or whatever it's called) to change the URL fields from
pointing at (whatever they point at) to pointing to the 2005-09-10-09-mozilla1.8
(like the current one).

Run the executable file to see if the installer still contains the bug.
(In reply to comment #8)
> {{
> Not this bug, but while I'm there:
> 
> *2005-09-26-22-mozilla-1.8 could be renamed 2005-09-26-22-mozilla1.8 !?

(This has been fixed now.)

> *latest-mozilla1.8 misses a Stub-I link ... even an "outdated" one as gtk1 or
> mac currently have.

(Mac link is now "recent".)
Stub-I link still misses.

> }}
(In reply to comment #9)
> 2a. As a simpler first step, look at the file sizes as listed in config.ini. 

{{
I believe another bug is opened for this:

File: talkback.xpi 	4 KB 	13/09/05 	20:57:00

v1.0a release talkback xpi did not actually contain the software.
}}


nightly/contrib/2005-09-08-17-mozilla1.8
nightly/contrib/2005-09-10-09-mozilla1.8 (v1.0a release)

[Component QFA]
Description Short=Quality Feedback Agent
;*** LOCALIZE ME BABY ***
Description Long=for reporting SeaMonkey crash information
Archive=talkback.xpi
Install Size=870
Install Size System=1
Install Size Archive=248
Attributes=SELECTED|FORCE_UPGRADE
Force Upgrade File0=[SETUP PATH]\components\fullsoft.dll

[Component RPT]
Description Short=Website Reporter
;*** LOCALIZE ME BABY ***
Description Long=Website Reporter
Archive=reporter.xpi
Install Size=480 Install Size System=1 Install Size Archive=1
Attributes=SELECTED|FORCE_UPGRADE
Force Upgrade File0=[SETUP PATH]\chrome\reporter.jar

Sizes were wrong, and there were 3 Unix line-endings in this Windows file.


nightly/contrib/2005-10-13-12-mozilla1.8

Sizes are correct :-)
Whole config.ini is in Unix format: unexpected on Windows, but seems to be
working :-| (same for Install.ini)


Then, I'm ready to R.Fixed this bug;
but I'd like your input on the talkback file and the Unix format first.
Flags: blocking-seamonkey1.0b+
> Stub-I link still misses.

That's intentional, and we don't plan to upload contrib stub-installers for
nightlies, it's too much work with too many possibilites for problems and too
little to gain.

> v1.0a release talkback xpi did not actually contain the software.

That's intentional, no bug, and can't be changed, as only Mozilla Foundation can
include talkback in builds, and we never had branch builds made up by them,
including the Alpha release, maybe also later releases...

This bug can only be marked FIXED once people building a stub installer can
confirm it works correctly.
WFM with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051230 SeaMonkey/1.0b stub installer.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20051219 SeaMonkey/1.0b] (release) (W98SE)

V.WFM with SMv1.0b release Stub-I.
(WFM, because we don't know what fixed this bug.)
Status: RESOLVED → VERIFIED
Target Milestone: --- → seamonkey1.0beta
How about you take a look at trunk first and do not verify your own resolved bugs? In trunk builds this is not resolved.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
Target Milestone: seamonkey1.0beta → ---
Version: 1.8 Branch → unspecified
(In reply to comment #14)
> (WFM, because we don't know what fixed this bug.)

But, per comment 11, it would seem to have been fixed (on branch) between 2005-09-10 and 2005-10-13.

(In reply to comment #15)
> How about you take a look at trunk first and do not verify your own resolved
> bugs? In trunk builds this is not resolved.

Well,
I did not check the Trunk (again) because I had already done so in comment 5;
and I verified the resolution for myself, after resolving it per (my comment 11 and) Bruno's comment 13.

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051230 SeaMonkey/1.5a] (nightly) (W98SE)

Unfortunately, now I confirm that SMv1.5a Trunk regressed between 2005-10-12 and 2005-12-30 :-<
(Thanks for noticing.)
(In reply to comment #16)
> Unfortunately, now I confirm that SMv1.5a Trunk regressed between 2005-10-12
> and 2005-12-30 :-<

One-day timeframe: nightly/2005-10-26-11-trunk <-> nightly/2005-10-27-18-trunk.
Ok the problem seems to be this if i see this correctly: Install Size Archive is now always 1 in the config.ini file. http://lxr.mozilla.org/mozilla/source/xpinstall/packager/windows/makecfgini.pl#155 tries to get this number from the function in line 288. Also the line endings as already noticed changed from Windows to Unix. So maybe something changed in the tinderbox configuration, like updated Perl from Cygwin? Also it might be this bug is already resolved again in current Cygwin versions of it (the bug on 1.8 branch got resolved and those tinderboxen get run by private people for the SeaMonkey project)? I think we need to file a bug on the mozilla.org product.
Depends on: 322064
Status: REOPENED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
Why was this bug mark FIXED?  I can't see any sign that this has been solved.  Unles it is actually working in the latest nightly?  In which case, without a bug reference, it should be WORKSFORME.  But if the bug persists, and it needs to be filed under a difference product, then it should be kept open and just have its product changed.

Reopening for correct resolution (or reference to the bug that fixed this).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #19)
> Why was this bug mark FIXED?
I marked this bug as fixed. Frank Wein told me yesterday, that with the fix for bug 322064, the trunk stub installer works again. I don't know what fixed the branch installer, so branch is WFM and trunk WFM & Fixed.
The resolution field is for trunk, so marking FIXED again.
Please do NOT reopen unless you see this still happening on current builds!
Status: REOPENED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
Robert,

> The resolution field is for trunk, so marking FIXED again.

I had understood that perfectly.  My previous comments still stands, however. I've actually downloaded the most recent trunk nightly to comfirm or not if this is now working.  It is.  (Although there was no comment that it was corrected on the trunk either - only the resolution change.)

But there is still no reference to *what* fixed this.  What bug is it that did this?  There's no patch attached to this one, so it must have been fixed by something.  Without a reference to the fix, only a WORKSFORME resolution should be used...
Also if it was, as you say, "updated Perl from Cygwin", then it was 3rd party software that corrected this, and not any SeaMonkey code change - so, again, WORKSFORME should be used.
Unless it's the dependency bug 322064 that did this?  If so, just clarifying that would be great. :)
WFM mean it never could be reproduced by a developer and is a useless report. FIXED means it was exisiting and has been fixed in some way.

Anyways, it's actually only nitpicking. Usually, bug that are RESOLVED are treated the same, regardless of their resolution - they have been successfully dealt with in any way, it actually doesn't matter much any mire in which way. The important thing is they are out of the way. And with forcing us to deal with your comments here, you're basically wasting time that could be spent on fixing more bugs and mire code.

So, just leave this bug alone and be glad it's not happening any more. We are as well. Whatever caused it, may it be the dependency or something else, seems to be gone. As long as it doesn't reappear, consider the item done. We have other stuff to deal with that's more important than hunting dead ducks (or whatever you may call it).
(In reply to comment #25)
> WFM mean it never could be reproduced by a developer and is a useless report.
> FIXED means it was exisiting and has been fixed in some way.
I think Jason is right - if we don't know *what* fixed it, we WFM.
V.Fixed,
on my W98SE, with
*nightly/contrib/2006-01-06-02-mozilla1.8.0
*nightly/contrib/2006-01-06-08-mozilla1.8
*nightly/2006-01-06-10-trunk
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.