Closed Bug 68643 Opened 24 years ago Closed 23 years ago

talkback in mac mozilla nightly builds

Categories

(SeaMonkey :: Build Config, defect, P2)

PowerPC
Mac System 8.5
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.2

People

(Reporter: jj.enser, Assigned: jj.enser)

Details

Attachments

(5 files)

Mac Mozilla nightly installer currently doesn't include any reference to 
TalkBack/FullCircle.
However, for milestone builds, we want to include this component to enable the 
crash feedback agent and collect useful debugging information from users.

This process requires to "manually" apply several modifications to the installer 
configuration which could be minimized by having a placeholder for Talkback with 
_every_ nightly build, the same way it's done on Win32 and Linux.
This way, when the time comes to release a milestone build, all we need to do is 
to overwrite the "minimal" talkback.xpi with the "real" one.

This bug is for me to keep track of this issue and come up with a solution 
comparable to the one implemented on other platforms.
changing summary to increase scope of bug.

chofmann has found some folks interested in helping mac testing but we need to
have talkback enabled mac mozilla nightly builds.  jj's going on vacation
tomorrow, not due back til 5/1.  IIRC, implementing this will require changes to
the mozilla build system to generate an empty talkback.xpi, changes to the
installer config to install the empty talkback.xpi, and changes to the build
automation to deliver the full talkback.xpi after the commercial build is done.

cc'ing sgadley and beard to see if they're willing and able to help out with this.
Summary: include a minimal fullcircle.xpi with mozilla nightly builds → talkback in mac mozilla nightly builds
from jj's email:

I don't think all this is too much work: adding the "empty" fullcircle.xpi to
daily mozilla builds comes down to the following tasks:
- create a valid install.js for that module -> sgehani can certainly manage that
(see existing mozilla/xpinstall/packager/mac/fullcircle.jst)
- add [fullcircle] section to packages-mac with nothing in it (or with a dummy
content if cannot be empty). Samir again.
- add the new component in the config.ini (or
xpinstall/wizard/mac/macbuild/config.ini_tmpl to be exact) so that the installer
stub knows about it. -> Samir again!

That's it. no change in the automation required.

To deliver the "full" talkback xpi, just replace the one under the appropriate
"mac-xpi" sub directory on ftp.mozilla.org or package a specific blob that
includes that .xpi file. I think either Samir, sfraser or pbeard can help with
this last one.
Shouldn't the last step be added to the mac automation for mozilla: i.e., grab
the ns fullcircle.xpi and upload it to the build's mac-xpi directory?  If so,
maybe you can add it to the automation before you leave for vacation, comment it
out with a big glaring note, and then have someone in release uncomment it once
I add stuff to automate the generation of a dummy fullcricle.xpi in mozilla.
Samir, what you suggest is probably a good idea for the long term, but it's not 
that easy to implement.
I'll try to submit a patch right here by the end of the day, but I cannot 
guarantee it.
Also, I realize that the values stored in the mozilla config.ini for
<Actual_Size> and <Archive_Size> for fullcircle.xpi would also have to be updated 
once the "fat" one replaces the empty one... not easy either.
Absolutely.  Didn't mean to trivialize the steps, just wanted to clarify that we
also need to make build automation changes, not just add a new dummy xpi. 
Thanks for enumerating the tasks at hand.  This sounds like a concerted effort
that can await your return.
Talkback doesn't really change size. Instead of generating these just hardcode 
approximate values into the config.ini (round up).

If you get to the "upload ns talkback" part there's no need to comment it out. 
Having an extra unreferenced file sitting on the server until the install 
itself is updated won't kill anyone, and it would allow mozillians who were 
interested to install by clicking on the .xpi once they've installed the rest 
of the product.
setting for 0.9 since we want to get this in asap, but since jj's out til 5/1,
doubt we have the resources to pull it off.
Target Milestone: --- → mozilla0.9.1
Priority: -- → P2
just did manual TB-enabled mozilla 0.9 release build. Same thing will probably 
happen for 0.9.1 since we haven't figured out a smooth way to automate this.

pushing to 0.9.2 until we know more.
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.1 → mozilla0.9.2
fix requires 2 patches and 1 new file added. (see attachments)

Samir, I have 2 questions (part of the review):
1. in packages-mac, does the [FullCircle] section requires to list one -dummy- 
file or can it be empty (unix has a dummy file, so I did the same for mac)
2. your fullcircle.jst includes a $version$ tag, which will be replaced with the 
smartupdate build id at packaging time. is this necessary or can we use "1.0.0.0" 
or any static version number instead?
Whiteboard: Fix in hand, need r=, sr=, a=
> 1. in packages-mac, does the [FullCircle] section requires to list one 
> -dummy- file or can it be empty (unix has a dummy file, so I did the same 
> for mac)

If your build automation will create a "FullCircle" directory and copy in the
generated install.js based on the FullCircle.jst install script template, then
no dummy file is needed.  You are in a better position to evaluate this.

> 2. your fullcircle.jst includes a $version$ tag, which will be replaced with 
> the smartupdate build id at packaging time. is this necessary or can we use 
> "1.0.0.0" or any static version number instead?

My FullCircle.jst is a dummy so you can replace it with a static version if
you'd like.  

Hope that helps! 
Samir:

my automation will not create a FullCircle installer module in any different way 
than it creates the others: it _relies_ on packages-mac. My question is: can I 
just add 1 line to that file with "[FullCircle]" in it or do I need to have at 
least another line trying to copy something for pkgcp.pl to do the right thing 
(i.e. create the directory).
I realize that Granrose might actually be in a better place to answer that 
question since he wrote pkgcp.pl... Jon?

ok regarding '$version$' in FullCirscle.jst

The whiteboard status still stands: Fix in hand, need r=, sr=, a=
JJ,
It would appear that the dummy file is not required:
<http://lxr.mozilla.org/seamonkey/source/xpinstall/packager/pkgcp.pl#479>
right.  pkgcp.pl creates the directory as soon as it sees the [component] line. 
 it doesn't require a file to be copied there.  But I don't know what the zip 
command to create the xpi file does if the directory is empty.
the zipping part is not a problem. it will process every directory found in the 
designated location, regardless of their content.

Samir & Jon: Thanks for your valuable input. Updated patches to packages-mac & 
fullcircle.jst coming up.
Whiteboard: Fix in hand, need r=, sr=, a= → Fix in hand, NEED r=, sr=, a=
r=sgehani for patch ids={37427, 37428}
Whiteboard: Fix in hand, NEED r=, sr=, a= → Fix in hand, HAVE r=, NEED sr=, a=
+ ; legitinate one for milestone builds, without breaking the

Fix spelling: "legitimate"

sr=sfraser

BTW, have we fixed the .xSYM file generation to ensure that we capture the 
appropriate .xSYM files for Talkback?
a=leaf
Simon, thanks for catching the typo :-)
The list of symbols file is still harcoded in BuildCentral, but I maintain it on 
a regular basis. (just updated before 0.9.1, little changes expected in 0.9.2)

However, I will log a separate bug to do it the Right Way (exporting each 
project's sym file afer it gets built, conditioned by MOZILLA_OFFICIAL or 
MOZ_FULLCIRCLE)
Whiteboard: Fix in hand, HAVE r=, NEED sr=, a=
Fixed.
Checked in:
mozilla/xpinstall/packager/mac/fullcircle.jst (1.1)
mozilla/xpinstall/packager/packages-mac (1.131)
mozilla/xpinstall/wizard/mac/macbuild/Installer Modules/config.ini_tmpl (1.27)

Changing QA contact to gbush so she can check tomorrow's installer (standard & 
custom install)
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
QA Contact: granrose → gbush
Resolution: --- → FIXED
verify on Mozilla build 2001070903 branch
trunk 2001070904
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: