740690 - Upgrade build slaves to GTK+-2.14 and GLib-2.18

Status: RESOLVED WORKSFORME

(Infrastructure & Operations Graveyard :: CIDuty, task)

Description

[Karl Tomlinson (:karlt)]

Upgrading build slaves to GTK+-2.14 and GLib-2.18 is proposed for bug 713802.

I would pick the most recent release in the series:
i.e. GTK+-2.14.7 and GLib-2.18.4.
I expect Pango and ATK upgrade dependencies also.

Bug 670707 may be an alternative but sounds like a major overhaul and I'm not
aware of much progress.

Comment 1

[Karl Tomlinson (:karlt)]

Attachment: ESR10: don't depend on GLib-1.16 and GTK+-2.14

If we don't want to keep some old build slaves around for 10ESR, upgrading
header files is going to add a runtime dependency on GLib-2.14, due to some
changes in GLib headers.

I don't see that as a problem because we dropped GTK+-2.10 support for
Firefox 7 in bug 666735 and GTK+-2.12 (the next GTK+ series) requires
Glib-2.14 (well Glib-2.13.5, in fact, but 2.14 is the stable series).

The changes in this patch for ESR10 will be needed to prevent future builds
depending on GLib-1.16 and GTK+-2.14.
(g_assert_not_reached() changed to a #define using g_assertion_message in
GLib-2.16.)
If we wanted, we could also make a change to avoid a GTK+-2.12 dependency
through gdk_event_request_motions, but we don't support GTK+-2.10 anyway.

Comment 2

[Justin Wood (:Callek)]

We will need to be well aware of what runtime dependencies in *every* train we would be changing with such an upgrade.

And for all trains likely needs someone from product to ok the runtime dependency changes. And be aware that we build Mobile as well on these same machines, so if upgrading any of this affects mobile runtime dependencies we need to care that we think about it.

There is work in the pipeline to make the environment we build each train in be independently upgradeable so we can avoid the "dependency on older branches is changing because of trunk software changes" but its not ready yet for this.

Comment 3

[Karl Tomlinson (:karlt)]

Given the propose update in depencies is very minor given the time since we switched to CentOS 5.0, if RelEng doesn't want to maintain two different build platforms, then I imagine putting this into production on all trains after April 24 is an option.

If it is put into production near the beginning of a cycle, then it gives us some chance to catch unexpected consequences, but, given distributions also provide their own builds, I can't imagine anything catastrophic.

There may be another possible option:

If RelEng would prefer to modify Fedora 12 reference platforms to also function as build systems, then that would raise the dependencies higher, but it could be effected gradually from initially m-c only, with other trains continuing with the CentOS 5.0 systems until the passengers arrive from the other trains.

Comment 4

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

(In reply to Karl Tomlinson (:karlt) from comment #3)
> Given the propose update in depencies is very minor given the time since we
> switched to CentOS 5.0, if RelEng doesn't want to maintain two different
> build platforms, then I imagine putting this into production on all trains
> after April 24 is an option.
> 
> If it is put into production near the beginning of a cycle, then it gives us
> some chance to catch unexpected consequences, but, given distributions also
> provide their own builds, I can't imagine anything catastrophic.
> 
> There may be another possible option:
> 
> If RelEng would prefer to modify Fedora 12 reference platforms to also
> function as build systems, then that would raise the dependencies higher,
> but it could be effected gradually from initially m-c only, with other
> trains continuing with the CentOS 5.0 systems until the passengers arrive
> from the other trains.

Landing this change for all trains at once is not really an option and neither is having two different pools of linux machines.  Let's look into using mock_mozilla and a modern-ish version of Fedora as build environment.  

Karl, one thing you could do to help this process is figure out the oldest version of other major distributions a build against Fedora 12 can run on.  Once we have the version of CentOS/Fedora we should be building on, we can start hooking Firefox/Fennec to mock_mozilla.

Comment 5

[Karl Tomlinson (:karlt)]

(In reply to John Ford [:jhford] from comment #4)
> Let's look into
> using mock_mozilla and a modern-ish version of Fedora as build environment.  

Thanks, John.  I see from your blog that you have been putting mock_mozilla to use.

> Karl, one thing you could do to help this process is figure out the oldest
> version of other major distributions a build against Fedora 12 can run on.

I wonder why you ask specifically about Fedora 12 if mock_mozilla is going to
be used instead of the Fedora 12 reference platform.  Is that a guess at a
sensible system on which to build?

Part of the answer to your question is the inverse of the GTK versions listed in Bug 713802 comment 18.

GTK+ 2.18 requires GLib 2.21.3 and so any platform with
GTK+ 2.18 will have GLib >= 2.22.  Fedora 12 has GLib 2.22 and so won't add
any additional GLib dependency.

The other major components that I expect to affect dependencies are gcc and
glibc.  gcc gets upgraded independent of the platform, so I'll ignore that.

Fedora 12 has glibc 2.11.  Using distrowatch data, all the distro versions
mentioned in Bug 713802 comment 18 except one should therefore run builds
against that glibc (and I expect they are the oldest versions that will).  The
exception is Evergreen.  OpenSUSE 11.2, with glibc 2.10.1 is not officially
supported but Evergreen is providing extended support.  (OpenSUSE 11.3 would
be fine.)

Given we don't win much from the newer GTK and GLib of Fedora 12, we could
pick an older version such as Fedora 10 and still have what we need from GTK
and GLib.  This should even allow our builds to run on Evergreen 11.1, but
that is not a priority.  Fedora 11 should make builds suitable for Evergreen
11.2.

However, Fedora 11 will provide only pulseaudio 0.9.15, which wouldn't satisfy
bug 662417 comment 5.

> Once we have the version of CentOS/Fedora we should be building on, we can
> start hooking Firefox/Fennec to mock_mozilla.

Is it an option to use Fedora 11, but upgrade pulseaudio?

Comment 6

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

(In reply to Karl Tomlinson (:karlt) from comment #5)
> (In reply to John Ford [:jhford] from comment #4)
> > Let's look into
> > using mock_mozilla and a modern-ish version of Fedora as build environment.  
> 
> Thanks, John.  I see from your blog that you have been putting mock_mozilla
> to use.
> 
> > Karl, one thing you could do to help this process is figure out the oldest
> > version of other major distributions a build against Fedora 12 can run on.
> 
> I wonder why you ask specifically about Fedora 12 if mock_mozilla is going to
> be used instead of the Fedora 12 reference platform.  Is that a guess at a
> sensible system on which to build?

I was under the impression that you liked Fedora 12 for some reason.  Re-reading shows me that you were suggesting using our existing Fedora 12 systems for building.  For many reasons, building on those Fedora 12 machines isn't really an option.

> Part of the answer to your question is the inverse of the GTK versions
> listed in Bug 713802 comment 18.
> 
> GTK+ 2.18 requires GLib 2.21.3 and so any platform with
> GTK+ 2.18 will have GLib >= 2.22.  Fedora 12 has GLib 2.22 and so won't add
> any additional GLib dependency.
> 
> The other major components that I expect to affect dependencies are gcc and
> glibc.  gcc gets upgraded independent of the platform, so I'll ignore that.
> 
> Fedora 12 has glibc 2.11.  Using distrowatch data, all the distro versions
> mentioned in Bug 713802 comment 18 except one should therefore run builds
> against that glibc (and I expect they are the oldest versions that will). 
> The
> exception is Evergreen.  OpenSUSE 11.2, with glibc 2.10.1 is not officially
> supported but Evergreen is providing extended support.  (OpenSUSE 11.3 would
> be fine.)
> 
> Given we don't win much from the newer GTK and GLib of Fedora 12, we could
> pick an older version such as Fedora 10 and still have what we need from GTK
> and GLib.  This should even allow our builds to run on Evergreen 11.1, but
> that is not a priority.  Fedora 11 should make builds suitable for Evergreen
> 11.2.
> 
> However, Fedora 11 will provide only pulseaudio 0.9.15, which wouldn't
> satisfy
> bug 662417 comment 5.

Updating pulseaudio might be a bit of a pain, but I bet we can do it.  I think it's also worthwhile involving metrics to see if we can figure out how many people on opensuse 11.2 are using our builds of Firefox.

> > Once we have the version of CentOS/Fedora we should be building on, we can
> > start hooking Firefox/Fennec to mock_mozilla.
> 
> Is it an option to use Fedora 11, but upgrade pulseaudio?

It might be, I'd have to verify.

Comment 7

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

Looks like I am able to create a Fedora 11 build environment successfully:

[cltbld@bld-centos6-hp-001 mock]$ mock_mozilla -r mozilla-f11-i386 --shell "cat /etc/issue"
INFO: mock_mozilla.py version 1.0.3 starting...
State Changed: init plugins
INFO: selinux disabled
State Changed: start
State Changed: lock buildroot
State Changed: shell
Fedora release 11 (Leonidas)
Kernel \r on an \m (\l)

State Changed: unlock buildroot

Comment 8

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

It would also be interesting to see if CentOS 6 is acceptable for building Firefox.

Comment 9

[Karl Tomlinson (:karlt)]

CentOS 6.0 has glibc 2.12, which is likely to cause trouble for Ubuntu 10.04 LTS
(and probably others).

Comment 10

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

Should get new versions as a by-product of bug 772446.

Comment 11

[Karl Tomlinson (:karlt)]

Mostly there.  Just comm-central builds remain, tracked in bug 794378

Comment 12

[Karl Tomlinson (:karlt)]

And SeaMonkey in bug 795354.