497108 - Create Qt enabled XULRunner builds

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P4)

Description

[Mark Finkle (:mfinkle) (use needinfo?)]

We have a Qt backend to Mozilla that is not used by Mozilla itself, but is used by external groups. Updates to Cairo (and other bits) frequently break the Qt backend.

We need a way to let Mozilla developers know a checkin broke the Qt backend, so we can address the issue quickly. Some breakages remain unfixed for weeks or longer.

Does Release Engr have the bandwidth to setup a simple "does-it-build" machine and have it report to the XULRunner tinderbox page?

Comment 1

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

(To clarify: This would not be a new qt-specific build machine. This would be a qt-build job added to the queue of jobs that are all handled by the same shared pool-of-slaves. This is how we handle all the different project branches, partner builds, l10n and xulrunner builds.)

For now, I'm putting this in Future until we get some time, but meanwhile I have some questions:

1) are the toolchains identical? Do you need anything installed different to what we currently use for Firefox, xulrunner, etc?

2) exactly where/how do we build Qt-enabled-xulrunner? Repack existing xulrunner with additional qt files? Or specific build using which Makefile targets, mozconfig?, env.variables, etc?

3) how frequently do you want Qt builds? Weekly? Nightly? Per commit? 

4) what o.s. do you want Qt build on? linux? mac? win32? linux-arm? wince?

5) Any preference on where we post these builds on ftp.m.o?

6) do you want qt showing up on its own tinderbox waterfall? as a column on one of the firefox waterfalls? someplace else? nowhere?

Comment 2

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to comment #1)
> 1) are the toolchains identical? Do you need anything installed different to
> what we currently use for Firefox, xulrunner, etc?

See https://wiki.mozilla.org/User:Pjohnsen/MozillaQtBuild
I use that to get my normal XULRunner build changed to build using Qt.

> 2) exactly where/how do we build Qt-enabled-xulrunner? Repack existing
> xulrunner with additional qt files? Or specific build using which Makefile
> targets, mozconfig?, env.variables, etc?

See #1
 
> 3) how frequently do you want Qt builds? Weekly? Nightly? Per commit? 

As frequently as we could without putting undue pressure on the buildbot slaves. Per commit would be great, but, personally, nightly would be good too.

> 4) what o.s. do you want Qt build on? linux? mac? win32? linux-arm? wince?

My opinion: Linux and maybe later we could look at Windows.

> 5) Any preference on where we post these builds on ftp.m.o?

As long as it's easy to get to. Posted Qt builds would be a great thing.

> 6) do you want qt showing up on its own tinderbox waterfall? as a column on one
> of the firefox waterfalls? someplace else? nowhere?

I initially thought about putting them on the XULRunner page, since it's really a Qt version of XULRunner.

(Anyone else have more to add - or want something different than I suggest?)

Comment 3

[Juha Seppänen]

We can also setup the machine and move the setup to Release Engr when they are able to handle it.

Comment 4

[Mark Finkle (:mfinkle) (use needinfo?)]

Just a note: mozilla-qt is currently broken again, after being fixed for a mere 5 days.

See 499135

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

Oops, sorry for the bugspam:
Bug 499135

Comment 6

[petri.rytinki]

What we have now done is a perl script that takes the latest changes and builds all in a "neverending" loop. After that it creates the needed logfile for TinderBox server and sends the file using HTTPPost. So I assume that all there is to do is to change the "tinderbox\@localhost" to something else ?  Also probably we have to check the "structure" or content of the created TinderBox logfile etc.

pseudo code version of the build script:

start loop
{
        if no build directories created
        {      
                hg clone "mozilla-central"
                hg clone "mobile-browser"
        }

        cd "mozilla-central"
        hg pull
        hg update

        cd "mobile-browser"
        hg pull
        hg update
       
        make -f ./client.mk build       

        create logfile for TinderBox
       
        HTTPPost http://localhost/cgi-bin/tinderbox/processmail_builds.cgi tinderbox\@localhost < logfile

        wait 60 minutes
               
} end loop

Comment 7

[petri.rytinki]

Of course, I meant that what has to be changed here is the first parameter (URL):

HTTPPost <URL> tinderbox\@localhost < logfile

If HTTPPost is the correct method to be used here?

Comment 8

[Chris Cooper [:coop] (he/him)]

Mass move of bugs from Release Engineering:Future -> Release Engineering. See
http://coop.deadsquid.com/2010/02/kiss-the-future-goodbye/ for more details.

Comment 9

[John Ford [:jhford] CET/CEST Berlin Time]

(In reply to comment #0)
> We have a Qt backend to Mozilla that is not used by Mozilla itself, but is used
> by external groups. Updates to Cairo (and other bits) frequently break the Qt
> backend.
> 
> We need a way to let Mozilla developers know a checkin broke the Qt backend, so
> we can address the issue quickly. Some breakages remain unfixed for weeks or
> longer.
> 
> Does Release Engr have the bandwidth to setup a simple "does-it-build" machine
> and have it report to the XULRunner tinderbox page?

Would having firefox linux qt desktop builds solve this? bug 451129

Comment 10

[John Ford [:jhford] CET/CEST Berlin Time]

(In reply to comment #9)
> Would having firefox linux qt desktop builds solve this? bug 451129

Would doing a build of Firefox using QT be satisfactory?  This should give us the 'does-it-build' information.

Comment 11

[John Ford [:jhford] CET/CEST Berlin Time]

This bug is going to be fixed by work in 451129.  It will provide xulrunner builds as well as firefox desktop builds.

Comment 12

[Justin Wood (:Callek)]

(In reply to comment #11)
> This bug is going to be fixed by work in 451129.  It will provide xulrunner
> builds as well as firefox desktop builds.

Just to be clear John, does this (and Bug 451129) entail any escalation in "tier" support of the Qt builds in our support matrix? or is it merely a convenient way for "us" to notice if Qt breaks?

Comment 13

[John Ford [:jhford] CET/CEST Berlin Time]

(In reply to comment #12)
> (In reply to comment #11)
> > This bug is going to be fixed by work in 451129.  It will provide xulrunner
> > builds as well as firefox desktop builds.
> 
> Just to be clear John, does this (and Bug 451129) entail any escalation in
> "tier" support of the Qt builds in our support matrix? or is it merely a
> convenient way for "us" to notice if Qt breaks?

That is not my intention or my call.  They can be hidden on tinderbox while that choice is made.

Comment 14

[John Ford [:jhford] CET/CEST Berlin Time]

This has landed

http://hg.mozilla.org/build/buildbotcustom/rev/ba6837ddd5a1
http://hg.mozilla.org/build/buildbot-configs/rev/ff0c87df87d7