talkback in mac mozilla nightly builds

VERIFIED FIXED in mozilla0.9.2


18 years ago
14 years ago


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


Mac System 8.5

Firefox Tracking Flags

(Not tracked)



(5 attachments)



18 years ago
Mac Mozilla nightly installer currently doesn't include any reference to 
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.

Comment 1

18 years ago
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

Comment 2

18 years ago
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 or package a specific blob that
includes that .xpi file. I think either Samir, sfraser or pbeard can help with
this last one.

Comment 3

18 years ago
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.

Comment 4

18 years ago
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.

Comment 5

18 years ago
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.

Comment 7

18 years ago
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


18 years ago
Priority: -- → P2

Comment 8

18 years ago
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.
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Comment 9

17 years ago
Created attachment 37101 [details] [diff] [review]
Patch for mac mozilla installer to include FullCircle.xpi in both setup types (deselectable in custom setup).

Comment 10

17 years ago
Created attachment 37169 [details] [diff] [review]
[FullCircle] section added to packages-mac

Comment 11

17 years ago
Created attachment 37170 [details]
fullcircle.jst (install.js template for fullcircle.xpi)

Comment 12

17 years ago
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 "" 
or any static version number instead?
Whiteboard: Fix in hand, need r=, sr=, a=

Comment 13

17 years ago
> 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 
> "" 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! 

Comment 14

17 years ago

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 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 Jon?

ok regarding '$version$' in FullCirscle.jst

The whiteboard status still stands: Fix in hand, need r=, sr=, a=

Comment 15

17 years ago
It would appear that the dummy file is not required:

Comment 16

17 years ago
right. 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.

Comment 17

17 years ago
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.

Comment 18

17 years ago
Created attachment 37427 [details]
Updated fullcircle.jst (static version number)

Comment 19

17 years ago
Created attachment 37428 [details] [diff] [review]
Updated patch to packages-mac (no dummy file added)


17 years ago
Whiteboard: Fix in hand, need r=, sr=, a= → Fix in hand, NEED r=, sr=, a=

Comment 20

17 years ago
r=sgehani for patch ids={37427, 37428}


17 years ago
Whiteboard: Fix in hand, NEED r=, sr=, a= → Fix in hand, HAVE r=, NEED sr=, a=

Comment 21

17 years ago
+ ; legitinate one for milestone builds, without breaking the

Fix spelling: "legitimate"


BTW, have we fixed the .xSYM file generation to ensure that we capture the 
appropriate .xSYM files for Talkback?

Comment 22

17 years ago

Comment 23

17 years ago
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 
Whiteboard: Fix in hand, HAVE r=, NEED sr=, a=

Comment 24

17 years ago
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)
Last Resolved: 17 years ago
QA Contact: granrose → gbush
Resolution: --- → FIXED

Comment 25

17 years ago
verify on Mozilla build 2001070903 branch
trunk 2001070904
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.