171010 - GRE installer: Build using manifests developers maintain

Status: VERIFIED FIXED

(Core Graveyard :: Installer: GRE, defect, P1)

Description

[Curt Patrick (gone)]

Currently we are maintaing duplicate manefests from what the delopers maintain
for creating the GRE and the MfcEmbed installers.  We should be using the same
manifests.  

I will make a patch for my scripts and attach the patch to this bug.  Aka, you
can use my patches for a pattern of what needs to change in the official build
scripts for nightly builds.

Comment 1

[Curt Patrick (gone)]

Attachment: Patch 1 for the GRE installer develpment build scripts

Comment 2

[Curt Patrick (gone)]

Attachment: Modified mozilla\xpinstall\packages\pkgs-mfcembed-win file

Comment 3

[Curt Patrick (gone)]

Aki, here is my patch.  

Note that the gre installer build needs to replace the call to pkgcp that we
were doing with two calls pointing to manifest files under
mozilla\embedding\config.  Notice also that the /s options adds \bin to the path.

For mfcembed you need to leave the pkgcp call that is there now and add two new
calls pointing to two different manifest files under mozilla\embedding\config. 
As witht gre build, the /s option also adds \bin to the path for the pkgcp call
that get added (but leave it the way it was for the original call to pkgcp).

For this to work correctly when you test it you also need to replace
mozilla\xpinstall\packages\pkgs-mfcembed-win with the one I've attached to this
bug.  Turns out that we need a couple files which the developer's manifests
don't deliver, so I stripped the pkgs-mfcembed-win manifest down to contain just
those two files.

Comment 4

[Aki Sasaki]

Attachment: build-verification.pl patch

testing this.

Comment 5

[Aki Sasaki]

the installers are up there to test, in the 2002-09-26-14 dir.  Guessing we need
to test these tomorrow, and then if all's well we can check this stuff in monday.

Comment 6

[Curt Patrick (gone)]

Aki, I'm not understanding how your patch could have worked.  I'm pretty sure
that the manifest files in the mozilla\embedding\config directory expect to have
mozilla\dist\bin in the --source commandline setting.  So I would expect that:

+    system ("$ENV{MOZ_SRC}\\mozilla\\xpinstall\\packager\\pkgcp.pl --source
$ENV{MOZ_SRC}\\mozilla\\dist --destination $ENV{MOZ_SRC}\\stage --file
$ENV{MOZ_SRC}\\mozilla\\embedding\\config\\basebrowser-win --os dos --verbose
2>&1 ") &&

should have to be:

+    system ("$ENV{MOZ_SRC}\\mozilla\\xpinstall\\packager\\pkgcp.pl --source
$ENV{MOZ_SRC}\\mozilla\\dist\\bin --destination $ENV{MOZ_SRC}\\stage --file
$ENV{MOZ_SRC}\\mozilla\\embedding\\config\\basebrowser-win --os dos --verbose
2>&1 ") &&

Everything else looks okay.  Lets touch base on this, though.

Comment 7

[Aki Sasaki]

Attachment: update

better?
will test with a clobber build monday.

Comment 8

[Curt Patrick (gone)]

Comment on attachment 100938 [details] [diff] [review]
update

This looks good.  r=curt

Comment 9

[Aki Sasaki]

installer available for testing in 2002-09-30-10-trunk... nuked dist before
running build.

Comment 10

[Aki Sasaki]

hang on, gotta rerung that... didn't change the pkg file.

Comment 11

[Aki Sasaki]

ok, now ready for testing.

Comment 12

[Aki Sasaki]

bleah, with cleanup commands in the script, i'm missing all of gre/ under
gre.xpi.  will revisit this later.

Comment 13

[Charles Rosendahl]

Is this supposed to be resolved fixed?  If so, let's move it there so I know
what to focus on when looking at the new builds.

Thanks,
Charles

Comment 14

[Aki Sasaki]

not yet.

Comment 15

[Aki Sasaki]

looks like my respin in 2002-10-04-11-trunk has i18n.dll.

this patch doesn't have cleanup of stage/, but i'm thinking i want to check this
in and make that another bug, since it'll take a while to figure out.

Comment 16

[Curt Patrick (gone)]

Good idea.  That is an improvement on the current system (we'll be using the
right manifests) with no downside since the current system isn't cleaning up the
stage area either.  Incremental changes are a good thing.  Go for it.

Comment 17

[Aki Sasaki]

Comment on attachment 100751 [details] [diff] [review]
Patch 1 for the GRE installer develpment build scripts

r=asasaki

Comment 18

[Daniel Veditz [:dveditz]]

Comment on attachment 100938 [details] [diff] [review]
update

rs=dveditz

Comment 19

[Daniel (Leaf) Nunes]

Comment on attachment 100752 [details]
Modified mozilla\xpinstall\packages\pkgs-mfcembed-win file

super-rheeet=leaf

Comment 20

[Curt Patrick (gone)]

I just checked in the new pkgs-mfcembed-win.  Aki has moved his changes to the
build machine.  When he checks in his changes I'll also commit the removal of
pkgs-gre-win.

Comment 21

[Curt Patrick (gone)]

Well I have to confess to having made a thourough mess out of this bug.  The
xpi's have all the files in them, but the directory structure in the xpi's does
not match what the install scripts are expecting.  I think that, since Aki is
not cleaning up the stage\gre folder, enough files must be getting into his
build in the right places to fool the install scripts into thinking everything
is right, but there is no way that the right stuff is getting to QA.  How
embarrasing!

So, I have created ANOTHER patch which works in my development environment. 
Aki, looks like we need you yet again to sync up your build scripts with the
change I just made.  My patch needs to be merged with yours so that all the
changes go in at once or the install scripts will definitely be broken.

When everything is correct, running the build script for the gre installer
should create a dist\stage\gre\Embed folder and a dist\stage\gre\gre folder. 
These two folders (with their contents) and install.js are the only things that
should show up in gre.xpi.  Similarly, the the build script for the mfcembed
installer should create dist\stage\mfcembed\Embed and
dist\stage\mfcembed\gre_app_support which should be the only contents of
mfcembed.xpi besides install.js.

Comment 22

[Curt Patrick (gone)]

Attachment: Patch 2 for develper scripts.

Here is the patch described in the previous comment.

Comment 23

[Aki Sasaki]

Attachment: yet another bv patch

built to work with patch 102515.

Comment 24

[Aki Sasaki]

Attachment: fixing pkgs-mfcembed thing

Comment 25

[Aki Sasaki]

new installers available at
ftp://ftp.mozilla.org/pub/mozilla/nightly/2002-10-14-08-trunk

Comment 26

[Curt Patrick (gone)]

Comment on attachment 102841 [details] [diff] [review]
fixing pkgs-mfcembed thing

Thanks Aki.  This looks good.  r=curt

Comment 27

[Charles Rosendahl]

The files are the same as those in the corresponding files in the mozilla dist
in the same folder mentioned in comment 25.

It looks good.  On a tangential note, there appears to be something wrong with
the build's functionality, but that would be a different bug.  The build won't
load the embedding smoketests.

Comment 28

[Jimmy Lee]

Bummer.  Perhaps Ashish can answer about the embedding smoketests.

Comment 29

[[e-mail] (away - not reading bugmail)]

Comment on attachment 102515 [details] [diff] [review]
Patch 2 for develper scripts.

r=jbetak

(This is a prerequisite for bug 167610. I used it there with great success.)

Comment 30

[Daniel (Leaf) Nunes]

Comment on attachment 102841 [details] [diff] [review]
fixing pkgs-mfcembed thing

sr=leaf

Comment 31

[Daniel (Leaf) Nunes]

Comment on attachment 102515 [details] [diff] [review]
Patch 2 for develper scripts.

sr=leaf

Comment 32

[Aki Sasaki]

checked in.  in daily builds starting tomorrow.

Comment 33

[timeless]

hi guys, did anyone notice that mozilla.org instituted a code freeze for the
1.2b period? you've been checking into the trunk quite a lot without any
consideration for mozilla.org rules.

<blockquote src="http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey">
The tree is under tight control for Mozilla 1.2beta. It will remain open for
only driver-approved checkins until we branch for 1.2final on or around Oct 30
(that's three weeks).

Checkins to the trunk are being approved by [e-mail]. Including the
bug number, your reviewers, and a description of the fix will increase your
chances of approval. Please begin the subject of approval requests with [trunk
approval].
</blockquote>

you've also broken bugzilla.mozilla.org general procedure by verifying bugs that
you resolve. I know that some of you have been QA since at least n3gold, that's
nice. However whatever policy you followed inside netscape doesn't necessarily
apply outside.

Beyond that, policy decissions for mozilla.org are supposed to be public or
announced by [e-mail] or a module owner.

http://www.mozilla.org/owners.html lists the modules and their owners, the GRE
doesn't have one, so you can't be relying on some module authority to break the
tree rules or set policy.

Comment 34

[Daniel (Leaf) Nunes]

The code that i've reviewed has been packaging manifest stuff and build
automation. The build automation stuff has never required driver approval, and
neither has *most* build config stuff.

I gave a verbal go-ahead for curt to check in the changes that i sr'd, which
might be stretching the bounds of the "blanket approvals for build/config
changes," but i don't think packaging manifests are that much of a stretch.

Comment 35

[Charles Rosendahl]

The GRE Installer package looks good - matches the mozilla dist and the contents
of basebrowser/gre-win manifests.  Going forward, which manifests are we using
for packaging purposes, basebrowser-win and gre-win, or something else?

marking verified.

Comment 36

[Curt Patrick (gone)]

For GRE we are using:
  mozilla\embedding\config\basebrowser-win
  mozilla\embedding\config\gre-win

For MfcEmbed we are using:
  mozilla\embedding\config\gre-win-sup
  mozilla\embedding\config\basebrowser-win-sup
  mozilla\xpinstall\packages\pkg-mfcembed-win

...and it looks like I'm going to have to add one more manifest file to fix bug
#174619