The libXi patches are because Ubuntu ships a libXi package that's marked as if it's a new version, but doesn't contain the new XI stuff for some reason:
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/libxi/raring/view/head:/debian/patches/revert-xi2.3.diff The easiest fix is to mark the package as an old version of libXi, which will cause mutter to understand it has the old libXi, and not attempt to use the new libXi features. On Tue, Feb 12, 2013 at 2:06 PM, Sriram Ramkrishna <[email protected]>wrote: > Christmas has come early this year! This is fantastic news. Perhaps I > can try to get some volunteers to help file bugs on the build? What can we > do to make this a sustaining success? > > sri > > > On Mon, Feb 11, 2013 at 10:43 PM, Martin Pitt <[email protected]>wrote: > >> Hello fellow GNOME developers, >> >> this already came up as a side issue recently[1], but now we are at a >> point where have reasonably stabilized our GNOME jhbuild continuous >> builds/integration test server to become actually useful: >> >> https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/ >> >> This is building gnome-suites-core-3.8.modules, which currently >> consists of 160 modules. Builds are updated every 15 minutes, and >> triggered whenever there was a new commit in a module or any of its >> dependencies. This mostly uses the smarts of jhbuild, we just have >> some extra scripts around to pick the results apart for Jenkins and >> drive the whole thing [2]. You can click through all the modules, all >> their builds, and get their build logs. >> >> Right now there are 151 successes (blue), 5 modules fail to build >> (red), and 4 modules build but fail in "make check" (yellow). It's >> been like that for a week or two now, so I'd say we are doing >> reasonably well for now. Some details: >> >> Build failures: >> - colord: recently started depending on libsystemd-login, which we >> don't have yet; that's a fault on the Ubuntu side >> - e-d-s: calls an undeclared g_cond_timed_wait(), not sure what this >> is about >> - folks: this started failing very recently, and thus is a perfect >> example why this is useful (unqualified ambiguous usage of >> HashTable) >> - gst-plugins-bad: unknown type GStaticRecMutex; this might be due to >> recent changes in streamer? That smells like a case of "broken by >> change in dependency, needs updating to new API" >> - mutter: worked until Jan 7, now failing on unknown XIBarrierEvent; >> that might be a fault in Ubuntu's X.org packages or upstream, I >> haven't investigated this yet >> >> Test failures: >> - gst-plugins-good, empathy: one test failure, the other tests work >> - realmd: This looks like the test suite is making some assumptions >> about the environment which aren't true in a headless server? >> - webkit: I don't actually see an error in the log; we'll investigate >> this closer on our side >> >> This was set up by Jean-Baptiste Lallement, I mostly help out with >> reviewing the daily status and cleaning up after some build/test >> failures which are due to broken checkouts, stale files, new missing >> build dependencies, and so on. It's reasonably maintenance intensive, >> but that's something which the two of us are willing to do if this >> actually gets used. >> >> The main difference to Colin's ostree builds is that this also runs >> "make check", which is one of the main points of this: We want to know >> as soon as possible if e. g. a new commit in glib breaks something in >> gvfs or evolution-data-server. Where "soon" is measured in minutes >> instead of days/weeks, so that the knowledge what got changed and why >> is still fresh in the developer's head. That's also why I recently >> started to add integration tests to e. g. gvfs or >> gnome-settings-daemon, so that over time we can cover more and more >> functionality tests in these. >> >> To make this really useful, we can't rely on developers checking this >> every hour or every day, of course; instead we need push notifications >> as soon as a module starts failing. That's the bit which needs broader >> discussion and consent. >> >> I see some obvious options here what to do when the status of a module >> (OK/fails tests/fails build) changes: >> >> (1) mail the individual maintainers, as in the DOAP files >> (1a) do it for everyone, and let people who don't want this filter >> them out on a particular mail header (like "X-GNOME-QA:") >> (1b) do this as opt-in >> >> This most often reaches the people who can do something about the >> failure. Of course there are cases where it's not the module's fault, >> but a >> dependency changed/got broken. There is no way we can automatically >> determine whether it was e. g. a deliberate API break which modules >> need to adjust to, or indeed a bug in the depending library, so we >> might actually need to mail both the maintainers of the module that >> triggered the rebuild, and the maintainers of the module which now >> broke. >> >> (2) one big mailing list with all failures, and machine parseable >> headers for module/test >> >> This might be more interesting for e. g. the release team (we can >> CC: the release team in (1) as well, of course), but will be rather >> high-volume, and pretty much forces maintainers to carefully set up >> filters. >> >> My gut feeling is that we might start with (2) for a while, see how it >> goes, and later switch to (1) when we got some confidence in this? >> >> Opinions most welcome! >> >> Also, I'll gladly work with the developers of the currently failing >> modules to get them succeeding. I have full access to the build >> machine in case errors aren't reproducible. >> >> Thanks, >> >> Martin >> >> [1] >> https://mail.gnome.org/archives/desktop-devel-list/2013-January/msg00006.html >> [2] http://bazaar.launchpad.net/~jibel/charms/raring/jhbuild/trunk/files >> >> -- >> Martin Pitt | http://www.piware.de >> Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) >> >> _______________________________________________ >> desktop-devel-list mailing list >> [email protected] >> https://mail.gnome.org/mailman/listinfo/desktop-devel-list >> > > > _______________________________________________ > desktop-devel-list mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > -- Jasper
_______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
