Closed
Bug 740690
Opened 13 years ago
Closed 12 years ago
Upgrade build slaves to GTK+-2.14 and GLib-2.18
Categories
(Infrastructure & Operations Graveyard :: CIDuty, task)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: karlt, Unassigned)
References
Details
(Whiteboard: [refplatform][puppet])
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•13 years ago
|
||
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•13 years ago
|
||
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.
Reporter | ||
Comment 3•13 years ago
|
||
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•13 years ago
|
||
(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.
Reporter | ||
Comment 5•13 years ago
|
||
(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•13 years ago
|
||
(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•13 years ago
|
||
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•13 years ago
|
||
It would also be interesting to see if CentOS 6 is acceptable for building Firefox.
Reporter | ||
Comment 9•13 years ago
|
||
CentOS 6.0 has glibc 2.12, which is likely to cause trouble for Ubuntu 10.04 LTS (and probably others).
Comment 10•12 years ago
|
||
Should get new versions as a by-product of bug 772446.
Depends on: 772446
Whiteboard: [refplatform][puppet]
Reporter | ||
Comment 11•12 years ago
|
||
Mostly there. Just comm-central builds remain, tracked in bug 794378
Assignee | ||
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
Assignee | ||
Updated•6 years ago
|
Component: Platform Support → Buildduty
Product: Release Engineering → Infrastructure & Operations
Updated•5 years ago
|
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•