Closed Bug 373373 Opened 17 years ago Closed 17 years ago

Provide Talkback extension drop to community builds

Categories

(Release Engineering :: General, defect, P1)

Product:
Release Engineering
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: coop, Assigned: coop)

References

Details

Attachments

(1 file)

Allow for drop in prebuilt talkback packages
9.23 KB, patch
preed
: review+
Details | Diff | Splinter Review 
The calbld user was added as part of bug 369013 to facilitate community tinderbox builds of Calendar products. Unfortunately, Sunbird builds Talkback which is pulled from the internal mofo CVS repository. I'm not sure how we want to handle access in this situation, given that the calbld key will be in the hands of community members rather than MoCo employees.

What's feasible here?
* grant calbld read-only access to only the talkback section on the mofo/ repo (not sure this is even possible);
* move the talkback code to a new distinct repo with access for only the build users

Other ideas? I've talked to lilmatt about this already. The Sunbird team is actually moving away from trunk builds to branch-only builds to insulate themselves from that churn, so moving to Breakpad isn't really an option.
I'll bring up switching to Breakpad on trunk at the next meeting, but like you said, it doesn't help us much.
Blocks: 365662
Blocks: 371816
Assignee: server-ops → aravind
Now that 369013 should be working, what do you guys want to do with this.  I can grant calbld user access to the internal mofo repo, but this needs to come from others in the build team.

coop:  Since you are in that team, your say-so is good enough for me.

I was planning on removing these (read-only) build users from the repo, but I can leave this user in if this is the route we want to take.

Let me know either way.
Some options that have been put forward:

* allowing calbld user to access mofo/ repo;
* moving Talkback into its own read-only repo; and,
* creating a source drop of Talkback that could be used by community projects.

There are a bunch of licensing issues surrounding our use of the Talkback code. We briefly discussed at the build meeting this week whether we might run into some legal issues over this. I'm not sure about the legal ramifications of each of the above options. 
Does this include just the mozilla developed source to integrate talkback or the talkback client source code.  If this includes the talkback client source code we need to restrict access very carefully...
(In reply to comment #4)
> Does this include just the mozilla developed source to integrate talkback or
> the talkback client source code.  If this includes the talkback client source
> code we need to restrict access very carefully...

It's the actual Talkback client source.


This applies to SeaMonkey too, it's just been disabled on Mac for a very long time (bug 328854).
Blocks: 328854
Summary: calbld needs access to Talkback repository → Community build keys need access to Talkback repository
How do we want to proceed with this bug.  This is all currently under the private repository.  It would be hard to grant selective access to this repo.  The right way is to probably move the public pieces to svn or some other repo.

I need some direction from build/schrep about this.
Since this code rarely changes (last change was for UB), I *think* we are going to provide a Talkback source drop for the community Macs, and make a little addition to the tinderbox client code to use a source drop _or_ pull the Talkback sources from CVS.

I'll need to verify the licensing for all the files in the Talkback sources before proceeding.
Assignee: aravind → ccooper
None of the Talkback files in the mofo/ repo are missing the NPL, so we're golden for creating a source drop for the community machines.
Assignee: ccooper → preed
(In reply to comment #9)
> None of the Talkback files in the mofo/ repo are missing the NPL, so we're
> golden for creating a source drop for the community machines.

So it appears I was grep-ing for the wrong license string...this still remains to be determined. 


Is there any movement on this?  Not clear on where we stand or what the next action is.  Preed?
In addition to needing caminobld access to /mofo/fullsoft/talkback, we'll need some way to tag Talkback for our releases.  Nobody on our team (that I'm aware of) currently has write access to /mofo, other than through the soon-to-disappear cltbld account.
(obviously, if Tinderbox changes to not pull from /mofo, then we won't need write access - I just wanted to point out that read-only access to /mofo probably isn't enough given the current state of Tinderbox if nothing else changes.)
Assignee: preed → ccooper
I'm currently looking at the feasibility of doing a Talkback object drop for community builds.

I'm not sure how that will play with the need for Camino (and possibly others) to tag the Talkback sources for releases.
Status: NEW → ASSIGNED
Component: Server Operations → Build & Release
QA Contact: justin → preed
So here's the current state of this:

After some testing, we've determined that object drops won't work, but that it is possible to drop in Talkback extensions that have been compiled for the same product on the same platform for the same branch. I will need to make extension packages to fill the following matrix:

Sunbird:   Windows, Mac, and, Linux -> 1.8 and Trunk
SeaMonkey: Windows, Mac, and Linux  -> Trunk
Camino:    ???

mento: Is talkback disabled in the Camino configs because it doesn't work on Intel Macs? Is there a need for Talkback extension packages for Camino?

I will also need to adapt the tinderbox Talkback install process to drop these packages in appropriately.

If there are any of the above combinations that can be eliminated, please let me know before I create any unnecessary packages. 

I encourage all trunk-based projects to seriously consider moving to Breakpad ASAP. A good yardstick for this will be bug 379396...when Thunderbird is able to successfully move over, it should be ready for everyone. If any projects are considering making this switch in the near-term and can do without Talkback, please also let me know so I can further simplify the matrix.
Summary: Community build keys need access to Talkback repository → Provide Talkback extension drop to community builds
SeaMonkey would be happy to be a fast adopter of Breakpad, i.e. use it as soon as it's ready for us to use it.
As only trunk builds are generated by MoFo machines for us, we could avoid that whole Talkback topic and go straight to Breakpad in theory.
One problem I've mentioned in bug 380906 is that we don't know what socorro server we can use though, as it's not yet clear if there will be one server for everyone or a MoCo/rest split.
Depends on: 383125
coop, Talkback is only disabled in the checked-in configs because cb-xserve1 is the tinderbox using those configs, and it doesn't have access to the mofo repository.  Our official builds are still coming off of maya, which has roughly the same tinder-config, but with talkback turned on.
Currently active Camino builds are 1.0.x (MOZILLA_1_8_BRANCH), 1.5.x (CAMINO_1_5_BRANCH), 1.6.x (MOZILLA_1_8_BRANCH), and trunk.
(In reply to comment #18)
> Currently active Camino builds are 1.0.x (MOZILLA_1_8_BRANCH)

There's a typo there; that's MOZILLA_1_8_0_BRANCH for 1.0.x.
Barring feedback to the contrary from the Calendar team, I will be creating Talkback packages for the following product/branch/platform combinations:

SeaMonkey: Linux Trunk, Mac Trunk, Win Trunk (based on latest 2.0a1pre nighlties)

Camino: 1.8.0, Camino 1.5 tag, 1.8, Trunk (all based on most recent available nightlies)

Sunbird: Linux Trunk, Mac Trunk, Win Trunk (based on latest 0.6a1 nightlies)
         Linux 1.8, Mac 1.8, Win 1.8 (based on 0.5 release)

KaiRo: if you do need Talkback packages for SeaMonkey 1.8.0 & 1.8, please let me know. Those builds don't seem to be created on Moz-hosted machines which is the only reason I haven't included them up until now.
coop:
Talkback packages for 1.8 would probably be nice - the machines creating those nightlies (and our releases) are owned and administrated by me.
I don't think 1.8.0 still makes a lot of sense, as it has reached its EOL now.

For trunk, we hope to get breakpad included with bug 383125 so that we probably won't need Talkback then, but until this point it would still help a lot, I think.
KaiRo: I misunderstood re: 1.8 -> I thought these builds already had Talkback included. If they do not (and indeed, they don't appear to), then we can't make packages available for them. I'm just creating packages from existing Talkback compilations here, not building things from scratch.

That said, is there any reason why the SeaMonkey Windows trunk build has talkback disabled? I'll need to re-enable it if we're to get a Windows Talkback package for SeaMonkey.

I also recognize that Talkback is disabled for SeaMonkey Mac trunk, and I *do* plan to provide a package here somehow, since we moved this build onto the community network before this talkback issue was decided.
coop:
Ah, OK (on the 1.8 builds).

I don't know any reason why Talkback would be disabled on trunk, other than the Mac Universal build problem we encountered in bug 328854
(In reply to comment #23)
> coop:
> I don't know any reason why Talkback would be disabled on trunk, other than the
> Mac Universal build problem we encountered in bug 328854

OK, I'm going to enable Talkback on Windows and see what happens, and take a look at the Mac problem on an idle box somewhere.


Once the SeaMonkey team has access to their own Windows VM (which is coming soon, pending bug 373373), they can decide if/how to tackle this bug.
Assignee: ccooper → kairo
Status: ASSIGNED → NEW
QA Contact: preed → ccooper
Oops, wrong bug reassigned.
Assignee: kairo → ccooper
Status: NEW → ASSIGNED
QA Contact: ccooper → preed
I'm running some test Camino builds with the repackaging code + packages on cb-xserve01 right now. Depending how this goes, I'll post some tinderbox patches for review.
The current Talkback tarballs and tinderbox scripts are working in that Talkback is picking up crashes on ppc and sending them to the Talkback server.

But:

The build ID is hardcoded in the tarball's master.ini file, and isn't changed at all during the packaging phase.  This causes the Talkback server to match up each crash report with the same (incorrect) set of symbols, and to lump all of the crash reports into a single build ID.

Talkback reads the build ID to report (and other identifying information about the application) from master.ini.
(In reply to comment #28) 
> The build ID is hardcoded in the tarball's master.ini file, and isn't changed
> at all during the packaging phase.  This causes the Talkback server to match up
> each crash report with the same (incorrect) set of symbols, and to lump all of
> the crash reports into a single build ID.

I have a patch to fix this -> it has correct set the build ID for Sunbird build I tested it with. 

I'll push the patch to the Camino xserve now and trigger a clobber on the trunk build to test that it handles the Camino directory layout as well. 

Trunk seems busted right now, so I'll try with Cm1.6-M1.8 instead.
This patch allows for drop-in, prebuilt Talkback packages.

Talkback packages are made per product/platform/branch, and each package contains:

* the prebuilt Talkback "extension" in the proper location for that product, relative to the $builddir; and, 
* the base fullsoft/Makefile.in (branch-specific)

The patch re-uses existing tinderbox functions where possible, e.g. finding the master.ini path and finding the build ID. We also re-use the existing fullcircle-push logic in the fullsoft Makefile, rather than transcribing those actions into tinderbox. 

I've snuck in some return value checking for the Talkback calls in tinderbox.

I've also added a new var, $MofoRoot, to the tinder-config/defaults. This will require updates to any configs that currently pull Talkback from CVS, but in so doing, I'm volunteering to make those changes.
Attachment #269124 - Flags: review?(preed)
Priority: -- → P1
Comment on attachment 269124 [details] [diff] [review]
Allow for drop in prebuilt talkback packages

Looks fine; one thing:

>+sub setBuildIdInTalkbackMasterConfig
>+{
>+    my ($talkback_client_path, $new_build_id) = @_;
>+    if (-e "$talkback_client_path/master.ini") {
>+        open (MASTERCOPY, ">$talkback_client_path/master.ini.copy") or return 0;
>+        open (MASTER, "$talkback_client_path/master.ini") or return 0;
>+        while (<MASTER>) {
>+            s/^BuildID = "(\d+)"/BuildID = "$new_build_id"/;
>+            print MASTERCOPY;
>+        }
>+        close (MASTER);
>+        close (MASTERCOPY);
>+        File::Copy::move("$talkback_client_path/master.ini.copy", "$talkback_client_path/master.ini") or return 0;
>+        return 1;
>+    }
>+    
>+    return 0;
>+}

Since this is a new function, can we do the args-handling method, so the call looks something like setBuildIdInTalkbackmasterConfig(clientPath => $a, newBuildId => $b);

Other than that, thanks for trial-and-error-ing this patch to death. I know it was... unpleasant to have to deal with ;-)
Attachment #269124 - Flags: review?(preed) → review+
Tinderbox changes have been checked in. 

I'll be pushing out the Talkback packages themselves to the various community machines/VMs tomorrow morning, and then doing a round of tinderbox config changes immediately after to start using the packages.
When arriving at the nightly build cycles (which build Talkback), the tinderboxen that are supposed to include Talkback went red with "Talkback processing failed."
(In reply to comment #31)
> I've also added a new var, $MofoRoot, to the tinder-config/defaults. This will
> require updates to any configs that currently pull Talkback from CVS, but in so
> doing, I'm volunteering to make those changes.
> 

Checking in this change now across the board to fix the bustage.

I've uploaded the Talkback packages to the various community boxes, and checked-in tinderbox configs changes across the board to fix the brokenness.

If any builds remain broken after the next cycle, please let me know.
The only outstanding issue of which I am aware is the lack of Talkback on SeaMonkey trunk Mac. Given that there is still a packaging issue there, the extension would be PPC-only anyway, and Breakpad is not far off, I'm content to close this out.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Chris, this seems to be working from a build perspective.  We're not seeing symbolization of reports sent yet although everything that I can see (including symbol upload) seems fine, so I'll pursue that separately with Jay.
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: