218898 - talkback for nightly builds. (non-installer builds)

Status: VERIFIED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Adam Hauner]

I downloaded 
http://ftp.mozilla.org/pub/mozilla/nightly/latest-1.4.1/mozilla-win32-installer.exe
(20030906) and installed Mozilla, first time with custom (Navigator & Talkback
only), second time with full. Though TalkBack XPI was downloaded by setup (947
bytes?), TalkBack wasn't installed.

Comment 1

[Bill Mason]

This also occurs with the full installer mozilla-win32-installer-sea.exe

Comment 2

[Daniel (Leaf) Nunes]

There was an issue with the talkback servers accepting symbols at the time the
build was done... i think this prevented the client from getting included in the
mozilla build.

Since it is questionable whether we're going to have access to talkback in the
coming months, i'm not sure how critical it is to have it in this release.

I can try respinning if it's deemed too important to ship without.

Comment 3

[Bill Mason]

1.4.1 has shipped, removing 1.4.1 blocker nomination.  Nominating for 1.4.2.

Comment 4

[Benjamin Smedberg]

*** Bug 223758 has been marked as a duplicate of this bug. ***

Comment 5

[Bill Mason]

Version 1.4 -> Trunk
Resummarizing
Changes reflecting duped bug 223758.

Comment 6

[Hermann Schwab]

Latest builds missing talkback: 2003102504, 2003102104, 2003100404.
For more info about this, and what is in the 1k talkback.xpi see bug 223758

Today I´ve looked at the available nightlies at
http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/

normal size of talkback.xpi in windows-xpi is 254k, in linux-xpi 805k
if talkback.xpi is replaced by a placeholder, only containing installer.js to
write a message to the log, size is only 1k on both systems.

oldest available folder, ok, was
http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/2003-09-03-04-trunk/

looking at the -04 builds, or others, if not available I found:

http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/2003-09-22-09-trunk/
mozilla-win32-talkback.zip      22-Sep-2003 19:06  10.5M
mozilla-win32.zip               22-Sep-2003 19:06  10.5M
talkback.xpi                    22-Sep-2003 20:06     1k
both zips have same size, but there should be a difference of .3M, so in the
windows-xpi folder talkback.xpi is only 1 kb.

http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/2003-09-27-04-trunk/
http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/2003-10-04-04-trunk/
http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/2003-10-21-04-trunk/
http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/2003-10-25-04-trunk/
mozilla-win32.zip only,   
no mozilla-win32-talkback.zip, and talkback.xpi 1k

Linux:
http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/2003-09-29-22-trunk/
http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/2003-09-29-22-trunk/linux-xpi/
http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/2003-09-29-22-trunk/linux-xpi/talkback.xpi
talkback.xpi            30-Sep-2003 03:26     1k


Setting OS to all, as I´ve found one occurence of missing talkback on linux.
I´ve been looking at all available -04 (windows) folders, if not available on
some others, and only some linux folders in the vicinity.

oldest link shows win32.zip and win32-talkback.zip same size in MB, as some 900
bytes make no difference.
The newer folders are lacking win32-talkback.zip, if the win-xpi folder holds a
1kb sized talkback.xpi only.

is this a packaging issue only?

I remember months before, if talkback wasn´t working sometimes I installed from
windows-xpi, and was fine, but I also noticed folders had been updated.
How can I get yesterdays talkback working in todays build? 
Edit the date(BuildID) in manifest.ini contained in talkback.xpi?

Comment 7

[Benjamin Smedberg]

[e-mail]: copying talkback from one build to another won't help
anyone... talkback will "work" but the actual reports it sends will be useless.
The reason some/many builds don't have talkback is that mozilla.org doesn't have
all of the machines available which can save talkback symbols, and the ETA is
uncertain on getting them back.

Don't fret about it, it is being worked on.

Comment 8

[Hermann Schwab]

I don´t fret about this, as I understand that sometimes in the production of
software something goes wrong. What I´m missing in this bug is a statement, if
this is a bug at all (open since 1.4b), or a minor build bug, self-repairing,
fixed by the build of the next nightly, or a bug somebody has to fix by changing
something in the build scripts, or is it done deliberately, as you are saying now.
I´ve been seeing ;-) missing talkbacks for more than a year, and thought it to
be a minor problem, fixed in one of the next builds.
As 1.6a is coming, I wanted talkback back, so better bugs will be filed.
But the data I filed will be a waste of my time, if everybody besides me knew
about this in advance, without telling in this open bug that this behaviour is
intended.
So I also could save a minute by not downloading a talkback-enabled build, if
the servers aren´t working.
I´ve been aware that in the transition from Netscape to mozilla.org talkback
data couldn´t be easyly accessed by developers, servers could be not working,
but after I successfully sent some talkbacks to
talkback.mozilla.org/spiral-bin/Collector.dll I thought this to be working.

Comment 9

[Max Alekseyev]

Isn't this bug of Blocker severity?
Say, I cannot provide Talkback data for my bugreports because current nightly
builds don't have talkback application. ;(

Comment 10

[Serge Gautherie (:sgautherie)]

Bug 216827 comment 7 copy:
{
Mozilla Foundation is setting up a seperate infrastructure for Talkback. Stay
tuned for more details.
}

Comment 11

[Daniel (Leaf) Nunes]

We are still working on getting a mozilla.org talkback server set up...
talkback.mozilla.org is currently a redirect to a netscape server. The server is
being worked on, and i'm working on re-integrating talkback into the nightly builds.

Comment 12

[Daniel (Leaf) Nunes]

Attachment: patch to splitsymbols on windows instead of stripping

Rather than writing automation (as netscape had) to circumvent the build system
for symbol creation and splitting, i'm going to add it to mozilla's build
system.
(this is easier for linux, where the unstripped binaries from dist can be
collected and posted, in entirety, to the server).

Comment 13

[Benjamin Smedberg]

Comment on attachment 139639 [details] [diff] [review]
patch to splitsymbols on windows instead of stripping

Is this just for tarballs, or can we use the same mechanism for installer
builds? If we can use the same mechanism, we should separate this out into it's
own Mmakefile rule.

Comment 14

[Daniel (Leaf) Nunes]

It affects tarballs as well as installler builds, does it not? (the installers
get created from the package directory, not directly from dist, don't they?)

Comment 15

[Daniel (Leaf) Nunes]

Attachment: modify the "deliver" target to move .dbg symbols out of the way

Once this is in the tree, i'll add the deliver target to the packaging phase of
the build automation.

Comment 16

[Daniel (Leaf) Nunes]

Attachment: modify the "deliver" target to move .dbg symbols out of the way [Checked in: Comment 19]

Once this is in the tree, i'll add the deliver target to the packaging phase of
the build automation.

Comment 17

[Daniel (Leaf) Nunes]

Comment on attachment 140253 [details] [diff] [review]
modify the "deliver" target to move .dbg symbols out of the way
[Checked in: Comment 19]

Forgot to check this in before the freeze, seeking approval to help get windows
talkback builds automated.

Comment 18

[chris hofmann]

Comment on attachment 140253 [details] [diff] [review]
modify the "deliver" target to move .dbg symbols out of the way
[Checked in: Comment 19]

a=chofmann for 1.7a

Comment 19

[Serge Gautherie (:sgautherie)]

Comment on attachment 140253 [details] [diff] [review]
modify the "deliver" target to move .dbg symbols out of the way
[Checked in: Comment 19]


Check in: { 02/11/2004 10:56	uid504	mozilla/ Makefile.in	1.238 }

Comment 20

[Hermann Schwab]

http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/2004-02-19-14-1.7a/
still the dummy version of talkback in the windows-xpi folder:
talkback.xpi            19-Feb-2004 14:36     1k  

So it seems we don´t get talkback with 1.7a

Comment 21

[Hermann Schwab]

Talkback is back

http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/experimental/2004-02-19-14-1.7a/mozilla-win32-1.7a-installer.exe

tested on Bug 234624
TB305888305W, TB30588982W sent to talkback.mozilla.org/spiral-bin/Collector.dll
Zonealarm asks to sent to 213.157.0.193:DNS

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7a) Gecko/20040219

I couldn´t copy the selected TalkbackIds from the record, had to enter them
manually. That is definitely a regression, but it is fine, that Talkback is back.

Comment 22

[Andreas Kunz]

Non-installer versions (=zip) do still not include talkback (in the place linked
above). Is this intended and is this going to change?
I'd hope so, especially because I don't think just including it is a lot of work.

However, at least there also is a full talkback.xpi one can install to a zip
version. It sort of works: Mozilla crashes on exit afterwards (TB30606409Y), but
at least talkback comes up then. Ok, no crash might actually be better, but at
least this proves it is working... :-)
BTW: my crash was sent to 207.200.79.6, which resolves to
talkback-s01.websys.aol.com and should be the correct server while the one
mentioned in comment #21 seems to be a proxy.

TB30606897M is a crash with a testcase for bug 194952, in case anyone wants to
check if the information gathered with a zip+xpi build is correct.

(Aside note: getting ftp://ftp.mozilla.org/pub/mozilla.org/data/crash-data/ or
something similar running again in the long term would be great; let me know if
I can be of any help.)

Comment 23

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7a) Gecko/20040219] (W98SE)

Confirming that TalkBack is back (and ran "successfully" once...),
from the Windows installer release at least.

<talkback.exe> identifies itself as "v2.2.unofficial".


About comment 21:
File a new bug if the Cut&Paste behaviour is needed !? (It couldn't hurt.)

Comment 24

[Michael Lefevre]

The usual trunk builds don't have talkback (AFAICS), so I guess something needs
to be done here for 1.7b. If not, maybe this bug could be resolved?

(and regarding the copying of the talkback IDs - that's not a regression, it's
bug 70585)

Comment 25

[Hermann Schwab]

(In reply to comment #24)

> (and regarding the copying of the talkback IDs - that's not a regression, it's
> bug 70585)

I remember that for some weeks talkback IDs could be copied, then talkback was
missing, Mozilla relocated ...
IMHO this is a regression, as I remember having seen that working on Win98 &
WIn98SE for some weeks.

Comment 26

[David G King]

As this went in with 1.7b, I assume it is no longer blocking 1.7 (final).

Comment 27

[David G King]

So now I know from experience that Talkback is up and running in Mozilla 1.7b
(see TB2427K). Mind you, all the Netscape icons were a bit odd. (Maybe that is
for a seperate bug?).

Comment 28

[Michael Lefevre]

It didn't go in "for" 1.7b, it was added specifically to the one build for
release.  I assume this will again need doing manually for 1.7, and therefore
should be a blocker, unless the nightly builds are hooked up with talkback by
that point.

Comment 29

[David G King]

Ahhh, that makes sense. Adding info to the Whiteboard.

Comment 30

[Daniel (Leaf) Nunes]

the goal is nightly talkback for linux and windows by the time 1.7 candidates
are built; the details are finally shaken out with the servers, and automation
is being tested for linux today.

Comment 31

[Daniel (Leaf) Nunes]

Attachment: add talkback files to packaging manifest

this will cause warning messages for people that don't have talkback built, but
will make it easy to plug talkback into the nightly automation.

Comment 32

[Daniel (Leaf) Nunes]

Attachment: add talkback to linux packaging manifest

packages-unix patch

Comment 33

[Benjamin Smedberg]

Comment on attachment 144859 [details] [diff] [review]
add talkback files to packaging manifest

is "talkback-l10nini" correct?

Comment 34

[Brian Ryner (not reading)]

Comment on attachment 144859 [details] [diff] [review]
add talkback files to packaging manifest

That should be talkback-l10n.ini (note the dot).  sr=bryner with that fixed.

Comment 35

[chris hofmann]

Comment on attachment 144859 [details] [diff] [review]
add talkback files to packaging manifest

a=chofmann for 1.7

Comment 36

[chris hofmann]

Comment on attachment 144864 [details] [diff] [review]
add talkback to linux packaging manifest

a=chofmann for 1.7

Comment 37

[Daniel (Leaf) Nunes]

Attachment: patch installer template and Makefile for symbol cacheing

Now that the files are in the package manifest, the installer should try and, i
don't know, install them.

I'm going to test the installer for what happens when talkback is not present
and make sure the installer doesn't fail horribly.

(the makefile change is to make it a little easier to track what symbols go
with what buildid on the build systems, and tie it to the build_number, as the
master.ini is)

Comment 38

[Daniel (Leaf) Nunes]

Comment on attachment 145136 [details] [diff] [review]
patch installer template and Makefile for symbol cacheing

more talkback installer/build changes

Comment 39

[Daniel (Leaf) Nunes]

Comment on attachment 145136 [details] [diff] [review]
patch installer template and Makefile for symbol cacheing

Yes, this patch causes the installer to fail horribly if there is nothing in
the talkback.xpi file to uncompress. I'm going to workaround this by adding a
dummy entry in the packages-win file so there will be *something* to uncompress
to prevent the installer from failing.

Comment 40

[Daniel (Leaf) Nunes]

Attachment: add the license file to the talkback package to ensure there's *something* to install

workaround for installer failure for non-talkback installer builds.

Comment 41

[chris hofmann]

Comment on attachment 145136 [details] [diff] [review]
patch installer template and Makefile for symbol cacheing

a=chofmann for 1.7

Comment 42

[chris hofmann]

Comment on attachment 145136 [details] [diff] [review]
patch installer template and Makefile for symbol cacheing

a=chofmann for 1.7

Comment 43

[Benjamin Smedberg]

Comment on attachment 145136 [details] [diff] [review]
patch installer template and Makefile for symbol cacheing

I'm still confused as to what happens when we aren't shipping talkback... are
we shipping dummy talkback.exe files, or are we shipping a dummy talkback.xpi?

Comment 44

[Daniel (Leaf) Nunes]

(In reply to comment #43)
> (From update of attachment 145136 [details] [diff] [review])
> I'm still confused as to what happens when we aren't shipping talkback... are
> we shipping dummy talkback.exe files, or are we shipping a dummy talkback.xpi?
> 

attachment 145138 [details] [diff] [review] addresses the case where talkback (for whatever reason)
doesn't get built.... we don't have dummy talkback files, but i added the
license file so that xpinstall wouldn't die on an empty xpi. I picked the
license file which, now that i think about it, might be a bad choice for a dummy
file, since this particular xpi should actually have a different license. I can
switch it to the README.txt, or we can another dummy textfile to keep xpinstall
happy.

Comment 45

[Andreas Kunz]

[e-mail] (re: blocking1.8a?):
Why do you think this bug that only affects nightlies should block a release
(that by definition does not have this bug)?

Setting this flag makes even less sense to me when I see that this bug already
has blocking1.7+...

Comment 46

[Andrew Hagen]

Good point. You can't nominate a bug for a nightly build. Now that 1.7 final is
frozen, it would be really great to have this bug fixed by the time 1.8a is
released.

Comment 47

[Andrew Schultz]

with talkback.jst => 1.5, I get this message installing 4/11/04 nightly:
Error [-621]: An Installer module talkback.xpi (.xpi) failed to install

talkback.xpi is still empty, except for install.js

Comment 48

[OstGote!]

see Bug 240234 for a new regression

Comment 49

[Andrew Hagen]

The 1.7-latest nightly builds have Talkback. Is this problem fixed?

Comment 50

[Ashley Bischoff (blog at handcoding.com)]

(In reply to comment #49)
> The 1.7-latest nightly builds have Talkback. Is this problem fixed?

Does that include both the .exe and .zip nightlies?

Comment 51

[Andrew Schultz]

trunk builds are still busted on linux (no talkback)

Comment 52

[Andrew Hagen]

Sorry. I forgot.

Comment 53

[Daniel (Leaf) Nunes]

linux trunk nightlies have talkback now... sorry it took so long to merge the
changes i made for the 1.7 branch tinderbox back to the trunk automation!

Marking fixed; we're waiting for server bits that understand macosx for that
platform.

Comment 54

[Boris Zbarsky [:bzbarsky]]

leaf, I just downloaded the 2004-04-24-07 linux trunk tarball, untarred it,
started it, and sent it a SEGV signal.  Talkback didn't come up....

The same procedure works with the full-installer build from the same directory
(ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/2004-04-24-07-trunk/).

Note that the tarball size did increase by 800K or so on 4/22/2004, so I'm
guessing we're including talkback in the tarball... it just doesn't actually run
when the program crashes, as far as I can see.

Comment 55

[Daniel (Leaf) Nunes]

Reopening; thanks for the report, bz. I was afraid that our .tar.gz packages had
a pre-generated component registry. Just adding the talkback component doesn't
get it registered as an xpcom component. I'll try and get regxpcom added to the
talkback packaging steps.

In the meantime, a workaround is to remove compreg.dat from your installation
directory and restart; this should load all the components present and
regenerate compreg.dat with talkback included.

Comment 56

[Daniel (Leaf) Nunes]

fixed for trunk builds:
http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/2004-05-05-17-trunk/mozilla-i686-pc-linux-gnu.tar.gz

Comment 57

[Boris Zbarsky [:bzbarsky]]

Verified with this morning's Linux nightly.  Thanks, leaf!