Closed Bug 298670 Opened 18 years ago Closed 18 years ago

Build Firefox tarballs from the installer manifests

Categories

(Toolkit Graveyard :: Build Config, defect)

Product:
Toolkit Graveyard
Component:
Build Config
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: benjamin, Assigned: benjamin)

References

Details

Attachments

(4 files, 1 obsolete file)

Fix * globbing in the flat case, rev. 1 [checked in]
45.17 KB, patch
chase
: first-review+
chase
: approval-aviary1.1a2+
Details | Diff | Splinter Review
Fix * globbing in the flat case, rev. 1 (-w)
23.92 KB, patch
Details | Diff | Splinter Review
thunderbird windows changes
22.86 KB, patch
Details | Diff | Splinter Review
OS/2 build bustage fix
3.43 KB, patch
benjamin
: first-review-
Details | Diff | Splinter Review 
In order for the update MARs to be accurate, they must be built from the same
set of object files that are being shipped in the installer. This patch changes
the tarball build system to use the installer manifests when available (keeping
the status-quo on mac).
Chase, I'm going to be flying all day tomorrow and taking a personal day
Monday, so I hoping that you have the energy to land this or delegate it to
someone else. It has been tested on linux but not windows: I don't expect
windows difficulties, but it should be tested just to make sure that silly
as/cygwin perl or backslash delimiters don't trip us up.
Attachment #187193 - Flags: first-review?(chase)
Comment on attachment 187193 [details] [diff] [review]
Build tarballs using the installer manifests, rev. 1 [backed out]

Landing this needs to happen asap to test the update mechanism.
Attachment #187193 - Flags: first-review?(chase)
Attachment #187193 - Flags: first-review+
Attachment #187193 - Flags: approval-aviary1.1a2+
Comment on attachment 187193 [details] [diff] [review]
Build tarballs using the installer manifests, rev. 1 [backed out]

Checking in toolkit/mozapps/installer/packager.mk;
/cvsroot/mozilla/toolkit/mozapps/installer/packager.mk,v  <--  packager.mk
new revision: 1.10; previous revision: 1.9
done
Checking in xpinstall/packager/Packager.pm;
/cvsroot/mozilla/xpinstall/packager/Packager.pm,v  <--	Packager.pm
new revision: 1.7; previous revision: 1.6
done
Checking in xpinstall/packager/xptlink.pl;
/cvsroot/mozilla/xpinstall/packager/xptlink.pl,v  <--  xptlink.pl
new revision: 1.7; previous revision: 1.6
done
Checking in browser/installer/Makefile.in;
/cvsroot/mozilla/browser/installer/Makefile.in,v  <--  Makefile.in
new revision: 1.16; previous revision: 1.15
done
Attachment #187193 - Attachment description: Build tarballs using the installer manifests, rev. 1 → Build tarballs using the installer manifests, rev. 1 [checked in]
I'll put together the thunderbird patch for this.
The only .xpt files the latest .zip build had was browser.xpt where the previous
.zip had many .xpt files.  I thought this patch had worked but after installing
the installer I see many .xpt files in my components directory.

Upon further inspection, the Firefox respin had this error in its xptlink.pl output:

[adt]
[browser]
FAILED: get_file_length: No such file or directory
'/cygdrive/c/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla//dist/bin/xpt_link
/cygdrive/c/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla//stage/browser/bin/components/browser.xpt.new
/cygdrive/c/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla//stage/browser/bin/components/accessibility-msaa.xpt
...
/cygdrive/c/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla//stage/browser/bin/components/xultmpl.xpt'
failed at xptlink.pl line 144.

For comparison, a yesterday's release nightly had this output:

Linking .xpt files...
[abe]
[adt]
[browser]
[en-US]
[reporter]
[talkback]
[xpcom]
Linking .xpt files completed.

The only thing that springs out at me is the extra forward slash in the
arguments sent to xpt_link.  Since we're building those arguments in a different
way now I suspect this might be the cause of the error.  I committed a patch
just now to remove those extra slashes and started a respin on pacifica.
(In reply to comment #5)
> The only .xpt files the latest .zip build had was browser.xpt where the previous
> .zip had many .xpt files.  I thought this patch had worked but after installing
> the installer I see many .xpt files in my components directory.

Chase, what do you mean by a lot of .xpt files in your components directory
(i.e. how many)? the xpt linker should be linking almost all of them together
into browser.xpt, so I would expect you to only see browser.xpt and maybe one
for qfa and another one for xpcom. 

Or maybe I misunderstood your comment and you are saying that installer builds
now have a bunch of .xpt files with this patch where before you would have only
seen a couple. In which case, ignore my question.

(In reply to comment #6)
> Or maybe I misunderstood your comment and you are saying that installer builds
> now have a bunch of .xpt files with this patch where before you would have only
> seen a couple. In which case, ignore my question.

This is what I was describing.
Comment on attachment 187193 [details] [diff] [review]
Build tarballs using the installer manifests, rev. 1 [backed out]

I backed these changes out.

Checking in browser/installer/Makefile.in;
/cvsroot/mozilla/browser/installer/Makefile.in,v  <--  Makefile.in
new revision: 1.17; previous revision: 1.16
done
Checking in xpinstall/packager/xptlink.pl;
/cvsroot/mozilla/xpinstall/packager/xptlink.pl,v  <--  xptlink.pl
new revision: 1.9; previous revision: 1.8
done
Checking in xpinstall/packager/Packager.pm;
/cvsroot/mozilla/xpinstall/packager/Packager.pm,v  <--	Packager.pm
new revision: 1.8; previous revision: 1.7
done
Checking in toolkit/mozapps/installer/packager.mk;
/cvsroot/mozilla/toolkit/mozapps/installer/packager.mk,v  <--  packager.mk
new revision: 1.11; previous revision: 1.10
done
Bug 298976 pointed out other interesting problems that resulted from this patch.
I ended up fixing all the hideous tabs in Packager.pm, so this patch is a bit
rough: I'll attach a -w version for easier review.
Attachment #187510 - Flags: first-review?(chase)
Attachment #187193 - Attachment is obsolete: true
Attachment #187193 - Attachment description: Build tarballs using the installer manifests, rev. 1 [checked in] → Build tarballs using the installer manifests, rev. 1 [backed out]
Comment on attachment 187193 [details] [diff] [review]
Build tarballs using the installer manifests, rev. 1 [backed out]

Minusing since I backed out due to regressions.
Attachment #187193 - Flags: approval-aviary1.1a2+ → approval-aviary1.1a2-
Comment on attachment 187510 [details] [diff] [review]
Fix * globbing in the flat case, rev. 1 [checked in]

land asap, i'll respin, and we can test result with quick turnaround
Attachment #187510 - Flags: first-review?(chase)
Attachment #187510 - Flags: first-review+
Attachment #187510 - Flags: approval-aviary1.1a2+
Attachment #187510 - Attachment description: Fix * globbing in the flat case, rev. 1 → Fix * globbing in the flat case, rev. 1 [checked in]
Fixed on trunk, with a secondary fix for xptlink.pl to use `cygpath` when
necessary to convert cygwin-style paths.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Untested changes for Thunderbird windows builds. I also renamed basemail-win to
packages-static to be consistent with Firefox. Will test this later tonight at
home (where my static installer build lives)
This broke OS/2 because we follow the MSDOS path.

I'm removing $os completely because it is not used anymore.

I'm using $^O = to cygwin to decide to do the cygpath stuff,
Attachment #197452 - Flags: first-review?(bsmedberg)
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.