86068 - RFE: mozilla-talkback release and "nightly" RPMs.

Status: RESOLVED WONTFIX

(SeaMonkey :: Build Config, enhancement, P4)

Description

[Aleksey Nogin]

Currently, there does not seem to be any option to install talkback from RPM. Of
course, one can always download and install an .xpi separately, but that kind of
defeats the purpose of the RPM.

Comment 1

[Christopher Blizzard (:blizzard)]

Adding leaf for some advice.  This would be a good idea.

Comment 2

[Daniel (Leaf) Nunes]

There are two ways we can go here:

1.) blizzard builds with debug enabled, and then copies the debug objects
somewhere for the netscape talkback server to pick up at a later time, then
strips the symbols in dist before making the rpm packages

2.) blizzard punts his rpm build script to people behind the same firewall as
the talkback machines and lets them deal with making rpms.

2 makes more sense, and is more network-friendly. we should probably make rpms
be a package-type the same way .tar.gz is: in the build system itself.

would you mind attaching your build scripts, or the relevant commands for making
the rpm? 

Comment 3

[Jon Granrose]

I don't think either option will be a trivial fix.  Don't you have to do a
special build in order to be able to package it as an rpm?

I do agree that it would be good to have rpm generation be built into the build
scripts similar to the tarball generation, but actually getting the talkback
bits into an rpm is non-trivial and more of problem than getting talkback into
the mozilla bits (which took several months to get right).  Would it be easier
to have a separate talkback rpm that you install after the mozilla rpm?

Comment 4

[Daniel (Leaf) Nunes]

that was actually my first thought, but then we have to worry about keeping the
buildnumber from the talkback rpm match up with the build-time from the actual
rpm; not only that, but we have to hope that the stacks from blizzard's
non-debug, optimized builds match up with the symbols we have from our optimized
debug builds, built on a different machine with potentially different compilers.

It's pretty important to get symbols from the machine that actually does the build.

Comment 5

[Aleksey Nogin]

IMHO the second option (build RPMs along with other builds) would be better.
This way
A) The "nightly" RPMs will be built regularly, not just when Blizzard has time
for it (which sometimes means no nightly RPMs for a few days in a row)
B) There will be no time zone weirdness when the build id does not match the RPM
version (because the RPM version is in Eeastern time).

Comment 6

[Daniel (Leaf) Nunes]

blizzard, can you attach the script you're using to do builds? i guess i have to
RTF RPM M to tell our automation to use the tree we have built already to make
rpms out of. 

Comment 7

[Aleksey Nogin]

Obviously, I am not Blizzard, but here it goes anyway:

See http://lxr.mozilla.org/mozilla/source/build/package/rpm/ - it has most of
the stuff needed for creating RPMs.
As far as I understand, the normal procedure for building RPMs is approximatelly
following:

0) (Needs to be done once) Edit $HOME/.rpmmacros so that RPM knows where to look
for source and spec files and where to put the compiled packages.
IMHO, the following should be sufficient:
a) Add 
%_topdir <mozilla-root>/build/package/rpm
to $HOME/.rpmmacros
b) Create <mozilla-root>/build/package/rpm/{SRPMS,BUILD,RPMS/{noarch,i386}}

1) Put mozilla-source-<DATE>.tar.gz into the <path>/SOURCE directory

2) Copy <path>/SPECS/mozilla-DATE.spec.in into <path>/SPECS/mozilla-<DATE>.spec
and replace literal "DATE" with actual <DATE> everywhere in it. Note that the
.spec file is the file that contains all the actual scripts.

3) Run 
rpm -ba SPECS/mozilla-<DATE>.spec
This would produce a source package in SRPMS and binary packages in RPMS/i386

Step (3) will also produce the build tree in BUILD/mozilla, you can then use
that tree to create a talkback RPM out of it. I would suggest doing it in a
separate step so that the open-source RPMs are not mixed with the binary-only
one. In particular, if you do it in a separate step, step (3) would produce a
"proper" source package that does not mention any of the talkback stuff.

Comment 8

[Daniel (Leaf) Nunes]

thanks for the info. I don't know that i *want* to make source rpms; i think i'd
rather just produce binary rpms from the already-built tree, since we're already
*doing* the compiles (why compile twice?).

Comment 9

[Aleksey Nogin]

If you want to use an already compiled tree, you'll just need to skip my items
(2-3) and instead create your own SPEC file (based on the existing one) that has
an empty %prep and %build stage (just remove everything between %prep and %build
lines and between %build and %install) and  update the %install stage to take
files from existing tree instead of $RPM_BUILD_DIR/mozilla

As for the reasons to rebuild from source:
1) You can pass different options to configure and create more RedHat-specific
binaries instead of more Linux-generic ones.
a) In particular, you can dynamically link agains all the libraries that exist
in the RedHat release you are compiling for).
b) -with-default-mozilla-five-home=/usr/lib/mozilla (RPM puts lots of things in
there and it's the location that is the most consistent with the normal RedHat's
FS layout style).
2) Source RPMs make it easier for people to build binary RPMs on other platforms
(they only have to run "rpm --rebuild <name>.src.rpm).

P.S. What versions of RedHat are you thinking about compiling on? Currently
Blizzard compiles nigthlies for RH 7.x (on RH7.1, I believe) and milestones for
6.x (on RH6.2, I believe) and 7.x.

Comment 10

[Aleksey Nogin]

I've filed a separate RFE - bug #91101 ``"nightly" RPMs should be built on a
regular basis'' (BTW, what's the correct component for that one? I used
mozilla.org/miscellaneous, probably there is a better one).

Comment 11

[Ed Avis]

(Attempted feature-beg follows)

IMHO, talkback _nightly_ packages would be nice to have.  But talkback
_milestone_ releases as RPMs are much more important.  At present, users who run
milestone releases are torn between the .tar.gz or installer versions (which
have Talkback) and using an RPM (which is needed for easy deployment to lots of
machines, and for stuff which 'depends' on Mozilla).

I say this because it looks as though automatically adding Talkback could be
problematic.  But since milestone releases are relatively infrequent, it might
be possible to make Talkback RPMs by hand on these occasions.  That could be a
good 20/80 solution (if you assume that 80% of Mozilla users run milestone
builds).  Maybe you could even persuade Linux distributions to include the
talkback-enabled packages, which would greatly increase the Talkback user base.

Comment 12

[Aleksey Nogin]

While I agree with epa98 in that release talkback RPMs may be more important
then "nightly" talkback RPMs, I would imagine that building talkback RPMs
manually is not much easier than writing a script that would do this job
automatically. 

Anyway, adding release RPMs to summary.

Comment 13

[Jon Granrose]

triage - this is non-trivial and has to be done at Netscape since it's Talkback,
and it's non-critical since we already have talkback enabled mozilla installer
builds so P4/moz1.1

cc'ing lpham fyi as the up and coming seamonkey unix build person.

Comment 14

[Christopher Blizzard (:blizzard)]

-> leaf

Comment 15

[Aleksey Nogin]

Current moz1.0 Manifesto explicitly lists Talkback on Mac. Shouldn't we have
talkback RPMs before 1.0 as well? Talkback enambled Mozilla installed builds are
IMHO insufficient - it is so much easier and more convenient to use RPMs, that I
would imagine a significant majority of RedHat users currenlty run non-talkback
RPM builds.

Comment 16

[Andrew Schultz]

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

Comment 17

[Chase Phillips]

Mass reassign of open bugs for [e-mail] to [e-mail].

Comment 18

[J. Paul Reed [:preed]]

We don't create RPM packages (anymore?), so WONTFIX.