make sure tinderboxen work with suite rebranding

RESOLVED FIXED in seamonkey1.0alpha

Status

SeaMonkey
General
RESOLVED FIXED
13 years ago
13 years ago

People

(Reporter: Robert Kaiser, Assigned: Chase Phillips)

Tracking

Trunk
seamonkey1.0alpha
Bug Flags:
blocking-seamonkey1.0a +

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

13 years ago
I gotta look into tinderbox code to figure out where tinderboxen may break with
rebranding (renaming binaries is the key there) and prepare a fix for that, so
we can make the transition as smooth as possible.
(Reporter)

Updated

13 years ago
Flags: blocking-seamonkey1.0a+
Target Milestone: --- → Seamonkey1.0alpha
(Reporter)

Comment 1

13 years ago
It looks to me as if it would be enough to just change the binary and product
names in tinder-config.pl/tinder-defaults.pl and we should be done.

I'm not completely sure of that, but that's all I found when searching through
mozilla/tools/tinderbox
(Reporter)

Comment 2

13 years ago
From a mail from chase (reply to mine):

> From what my research showed, getting tinderboxen to go green again after
> renaming the binaries might be as easy as correcting the variables in the
> tinderbox configurations, see my last comment in bug 289846.

Yes, it should be that easy.  In practice we'll see as we make the changes where
things break. :)

[...]

Easiest way is to file bugs on the main issues and assign them to me.
Assignee: kairo → chase
(Reporter)

Comment 3

13 years ago
Chase, just as a note:
The real rebranding patch is up at bug 285696 and should have reviews soon.
This means, it will hopefully be able to land soon (meaning that I'd like it to
happen before 1.8b3) in a concerted effort with bug 292268 and bug 288199.

This comment is meant as a warning that those infrastructure issues might get
hot within a week or so. Stage can probably be prepared before that, tinderboxen
have to be fixed after the fact anyways.
(Reporter)

Comment 4

13 years ago
OK, we're ready to go code/patch-wise, but Chase is overloaded currently (no
time before the july 4 holiday) and can't do the infrastructure stuff atm.

We have to coordinate bugs 292268,285696,288199,289846,298901 to make it all
happen at once and make the transition as smooth as possible, so we'll push out
the whole thing a few days (this is all SeaMonkey-only so we don't have to care
about aviary 1.1a2 too much), I hope it'll be ASAP - still need to schedule an
impact date/time with Chase though.

Additionally, we'll have to wait a few days as well to get MoFo reviews on the
announcement which should go public in a tight timeframe around the happening of
those changes.
Please be warned it's coming up but patient at the same time.
(Reporter)

Comment 5

13 years ago
We have a problem with tinderbox config vs. build config on Mac now: a tinderbox
ProductName of "Mozilla" looks for Mozilla.app and a profile in
/Library/Mozilla/Profiles/, "SeaMonkey" for SeaMonkey.app and
/Library/SeaMonkey/Profiles/ - but we have SeaMonkey.app now, but the profiles
still in /Library/Mozilla/Profiles/ :-/

The tinderbox code in question is at
http://lxr.mozilla.org/mozilla/source/tools/tinderbox/build-seamonkey-util.pl#1080

From looking at that, including the BeOS case that is hardcoded, the
app-specific Darwin/MacOSX casing and that VendorName stuff, I'm starting to
think that Tinderbox might be better off using a variable for the app-specific
part of the profile name.

Not sure what's the right fix for now though...
(Reporter)

Comment 6

13 years ago
the easiest fix (quite hackish though) probably would be to set a ProductName of
"SeaMonkey" for those mac tinderboxes and add the following section before
http://lxr.mozilla.org/mozilla/source/tools/tinderbox/build-seamonkey-util.pl#1118

        } elsif ($Settings::ProductName eq 'SeaMonkey') {
            $profile_dir =
"$ENV{HOME}/Library/Mozilla/Profiles/$Settings::MozProfileName/";
That's really the way things should work, IMO.  There should really only be one
configuration variable for the "product" for tinderbox.  The scripts should then
be able to use that variable to get the right profile name, etc.
(Reporter)

Comment 8

13 years ago
OK, Chase fixed that problem with setting a "profile product name" of "Mozilla"
when the ProductName is "SeaMonkey".

So, now, SeaMonkey-Ports are green, only myotonic is back to its previous orange
about regxpcom and MozillaAliveTest failing.

Of the main SeaMonkey tinderboxen, the Linux ones are green, as is barcelona.

monkey is back to its previous orange (Can't open perl script "TestOutSinks.pl":
No such file or directory).

The only really still open tinderbox problem is creature, which fails at
packaging, probably due to the stub installer package naming thing I pointed out
and have a possible fix attached in bug 292268.
(Reporter)

Comment 9

13 years ago
Hmm, barcelona is red again, seemingly because ProductName is "Mozilla" instead
of "SeaMonkey":

/builds/tinderbox/Mozilla-Trunk/Darwin_6.8_Depend/mozilla//dist/Mozilla.app/Contents/MacOS/seamonkey-bin
does not exist.
(Reporter)

Comment 10

13 years ago
(In reply to comment #9)
> Hmm, barcelona is red again, seemingly because ProductName is "Mozilla" instead
> of "SeaMonkey":

Forget that. I'm dumb. I should not look at old tinderbox pages. :(
(Reporter)

Comment 11

13 years ago
OK, there's another small, but real issue still left:

lhasa still stages its builds in the wrong directory (mozilla instead of
seamonkey)...
(Assignee)

Comment 12

13 years ago
(In reply to comment #11)
> OK, there's another small, but real issue still left:
> 
> lhasa still stages its builds in the wrong directory (mozilla instead of
> seamonkey)...

lhasa takes a while to build and it's likely it had already started its 7/2
trunk build when I changed the FTP path in its configuration.  Do I see a
current GTK2 build in
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2005-07-04-08-trunk/ ?
 If so, it appears to be working correctly now.

Let's give it another day to be certain.  If everything is okay I'll remove
lhasa's seamonkey files from pub/mozilla/nightly/ and call it a done deal.
Status: NEW → ASSIGNED
(Reporter)

Comment 13

13 years ago
(In reply to comment #12)
> lhasa takes a while to build and it's likely it had already started its 7/2
> trunk build when I changed the FTP path in its configuration.  Do I see a
> current GTK2 build in
> http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2005-07-04-08-trunk/ ?
>  If so, it appears to be working correctly now.

Yes, looks you're right again. When I filed that comment, those builds weren't
there yet, but it's true, it uploaded them correctly.

Thanks for your help!

It seems the only problems left are monkey (which is a different thing as we
know) and creature (which we hope to get cleared).
(Reporter)

Comment 14

13 years ago
Thanks Chase, all tinderboxen (not counting monkey and myotonic which have
different problems not related to rebranding) are green and working correctly.

btek still has increased Tp, which is tracked in bug 299624

This bug is FIXED.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.