Re: Announcement/RFC: jhbuild continuous integration testing
On Wed, Feb 13, 2013 at 06:53:17AM +0100, Martin Pitt wrote: Travis Reitter [2013-02-12 13:21 -0800]: On Tue, 2013-02-12 at 07:43 +0100, Martin Pitt wrote: 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'd like to offer: (0) auto-file an urgent/critical bug against the module in the case of build breaks (and maybe high/major for test breaks?) Claudio Saavedra [2013-02-12 23:24 +0200]: (3) Automatically filing a bug in the broken module with the details of the breakage and additionally CC: whoever might be interested in keeping an eye on the continuous integration? This creates more overhead, but I like this proposal as well. I guess one can use python-bzutils and the like to auto-create bugs, and remember on the Jenkins side which bug was opened for which module, and auto-close it once the build works again. The main issue that I see with this is that it's much harder to filter away/opt out, so it requires some broader consensus that we want to do this. We can still add a module blacklist if needed, though. I think build issues should be filed as Bugzilla bugs. At most we maybe want to set some keyword / status whiteboard. But I guess the summary would be consistent and people will quickly learn of it. You can use information from DOAP files to figure out the Bugzilla product. This is not always needed. Then commit whatever DOAP fixes are needed (the DOAP files are not bug free :P. In case someone wants to opt out, we can add a new gnome-specific option to the DOAP file specifying that any Continuous Integration is not welcome. What I do in ftpadmin (see sysadmin-bin) is: - Check if there is a bug-database with 'bugzilla.gnome.org' For those URL(s): Check if the URL containers product=$SOMETHING - If there is a good product: use that - else: assume tarball = bugzilla product (will fail for jhbuild, often modules are renamed and you don't know the real one) Note: Not all products are on bugzilla.gnome.org. Maybe after GNOME bugzilla, strive for 'bugs.freedesktop.org'? For monitoring these bugs, you can easily watch people in Bugzilla. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcement/RFC: jhbuild continuous integration testing
On Wed, Feb 13, 2013 at 11:23:52AM +0100, Bastien Nocera wrote: On Wed, 2013-02-13 at 10:59 +0100, Olav Vitters wrote: On Wed, Feb 13, 2013 at 06:53:17AM +0100, Martin Pitt wrote: The main issue that I see with this is that it's much harder to filter away/opt out, so it requires some broader consensus that we want to do this. We can still add a module blacklist if needed, though. I think build issues should be filed as Bugzilla bugs. At most we maybe want to set some keyword / status whiteboard. But I guess the summary would be consistent and people will quickly learn of it. They should be filed as Bugzilla bugs *after a timeout*. We already see build failures on ostree popping up on the #testable channel, and those are usually fixed in a timely manner. Hmm, makes sense. Maybe start of small? -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcement/RFC: jhbuild continuous integration testing
On Wed, 2013-02-13 at 10:59 +0100, Olav Vitters wrote: I think build issues should be filed as Bugzilla bugs. At most we maybe want to set some keyword / status whiteboard. But I guess the summary would be consistent and people will quickly learn of it. Don't see a need for keywords here: Could filter by reporter account if a dummy account (e.g. jenkins-buildbot@gnomebugs) was set up that automatically files reports via Bugzilla's XML-RPC interface on build failure (if that's wanted). You can use information from DOAP files to figure out the Bugzilla product. This is not always needed. Then commit whatever DOAP fixes are needed (the DOAP files are not bug free :P. When I checked three months ago, 79 of 654 non-archived Git modules had no DOAP file at all. 287 out of 575 modules with a DOAP file had an entry for bug-database. GNOME does not even list bug-database in https://live.gnome.org/action/recall/Git/FAQ?action=recallrev=29#How_do_I_add_a_description_to_the_git_web_view.3F__What_is_this_.22blah.doap.22.3F andre -- Andre Klapper | ak...@gmx.net http://blogs.gnome.org/aklapper/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcement/RFC: jhbuild continuous integration testing
On Wed, 2013-02-13 at 10:59 +0100, Olav Vitters wrote: On Wed, Feb 13, 2013 at 06:53:17AM +0100, Martin Pitt wrote: Travis Reitter [2013-02-12 13:21 -0800]: On Tue, 2013-02-12 at 07:43 +0100, Martin Pitt wrote: 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'd like to offer: (0) auto-file an urgent/critical bug against the module in the case of build breaks (and maybe high/major for test breaks?) Claudio Saavedra [2013-02-12 23:24 +0200]: (3) Automatically filing a bug in the broken module with the details of the breakage and additionally CC: whoever might be interested in keeping an eye on the continuous integration? This creates more overhead, but I like this proposal as well. I guess one can use python-bzutils and the like to auto-create bugs, and remember on the Jenkins side which bug was opened for which module, and auto-close it once the build works again. The main issue that I see with this is that it's much harder to filter away/opt out, so it requires some broader consensus that we want to do this. We can still add a module blacklist if needed, though. I think build issues should be filed as Bugzilla bugs. At most we maybe want to set some keyword / status whiteboard. But I guess the summary would be consistent and people will quickly learn of it. They should be filed as Bugzilla bugs *after a timeout*. We already see build failures on ostree popping up on the #testable channel, and those are usually fixed in a timely manner. If you file the bugs as soon as they're visible, you'll end up filing outdated bugs, and severely reducing the good will of the people fixing those bugs. I don't think it would personally take me very long to yell I KNOW at the bugmail and want to opt-out. Bugmail should be for long-standing issues. If the problem can be solved under 10/15 minutes, don't start nagging people watching the bug mail. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcement/RFC: jhbuild continuous integration testing
On Wed, Feb 13, 2013 at 5:23 AM, Bastien Nocera had...@hadess.net wrote: If you file the bugs as soon as they're visible, you'll end up filing outdated bugs, and severely reducing the good will of the people fixing those bugs. I don't think it would personally take me very long to yell I KNOW at the bugmail and want to opt-out. Bugmail should be for long-standing issues. If the problem can be solved under 10/15 minutes, don't start nagging people watching the bug mail. Indeed, I've cleaned out plenty of 5-10 year old build breakage bugs from gtk bugzilla in the last week. Having failures from this system show up in #testing would be brilliant, on the other hand. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcement/RFC: jhbuild continuous integration testing
On 2013-02-13 11:58, Andre Klapper ak...@gmx.net wrote: When I checked three months ago, 79 of 654 non-archived Git modules had no DOAP file at all. 287 out of 575 modules with a DOAP file had an entry for bug-database. GNOME does not even list bug-database in https://live.gnome.org/action/recall/Git/FAQ?action=recallrev=29#How_do_I_add_a_description_to_the_git_web_view.3F__What_is_this_.22blah.doap.22.3F I just added a bug-database item to that DOAP template. Should we have a GNOME Goal to tidy up the DOAP files and add a minimum set of recommended fields? It might not be a great deal of use, so just some better guidance on the wiki would probably be sufficient. -- http://amigadave.com/ pgpHlNCm61kgi.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcement/RFC: jhbuild continuous integration testing
On Wed, 2013-02-13 at 18:44 +, David King wrote: On 2013-02-13 11:58, Andre Klapper ak...@gmx.net wrote: When I checked three months ago, 79 of 654 non-archived Git modules had no DOAP file at all. 287 out of 575 modules with a DOAP file had an entry for bug-database. GNOME does not even list bug-database in https://live.gnome.org/action/recall/Git/FAQ?action=recallrev=29#How_do_I_add_a_description_to_the_git_web_view.3F__What_is_this_.22blah.doap.22.3F I just added a bug-database item to that DOAP template. Should we have a GNOME Goal to tidy up the DOAP files and add a minimum set of recommended fields? It might not be a great deal of use, so just some better guidance on the wiki would probably be sufficient. That sounds like a good plan for 3.9. Comparing GNOME's usage of DOAP files with the DOAP usage in Apache Software Foundation there's a lot more that GNOME can improve though, but it will take me some time to outline it. Which I'll have in March again. Hopefully. If not, ping me. Please. andre -- Andre Klapper | ak...@gmx.net http://blogs.gnome.org/aklapper/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcement/RFC: jhbuild continuous integration testing
First, this sounds like really interesting stuff, great news. On Tue, Feb 12, 2013 at 3:43 PM, Martin Pitt martin.p...@ubuntu.com 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. Upon reading this particular part (and I noticed before you are using mostly jhbuild mechanics), it leads me to wonder, how granular exactly are these rebuilds ? I think ideally it would be great if builds could be triggered by commit. In other words, commits are serialized chronologically and each and every commit should trigger an entire rebuild, each rebuild should build everything in the moduleset up to the latest commit... separately, one after the other. I know, it sounds like some CPU will be melting quickly at the rate gnome-wide commits are made... but it would be simply awesome, if we could automatically pull out the exact commit which introduced exactly which failed build report in which module (and then as you mentioned, we probably need to notify both the
Re: Announcement/RFC: jhbuild continuous integration testing
On Thu, 2013-02-14 at 06:42 +0900, Tristan Van Berkom wrote: I know, it sounds like some CPU will be melting quickly at the rate gnome-wide commits are made... but it would be simply awesome, if we could automatically pull out the exact commit which introduced exactly which failed build report in which module (and then as you mentioned, we probably need to notify both the author of the commit, and the maintainer of the effected module). If basically you want to ensure that each commit is buildable, the best way to do that is to have builders try *queued patches*, not just master. That's how competently-run projects like OpenStack work; to pick a random example: https://review.openstack.org/#/c/21611/ You can see in Comment 2 the jenkins builder ran through a number of gating tests. I plan to do this eventually for the OSTree builder - the system is designed around cloning, so it should be quite cheap to clone the master builder, apply a patch series from bugzilla, build that, and run the tests. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Most compatible AND useful toolkit for use in GNOME
Hi, What are your recommendations for a toolkit that is best suited to GNOME app development (obviously GTK+3), but also useful in developing apps for other distros / OSs - I feel that the general suggestion is Qt. Others have said even wxWidgets, because it draws native widgets according to the environment. Keep in mind my language of choice is python (3) and am quite new to graphical app development. Thanks, -- Marco Scannadinari ma...@scannadinari.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcement/RFC: jhbuild continuous integration testing
hi; On 13 February 2013 22:11, Colin Walters walt...@verbum.org wrote: On Thu, 2013-02-14 at 06:42 +0900, Tristan Van Berkom wrote: I know, it sounds like some CPU will be melting quickly at the rate gnome-wide commits are made... but it would be simply awesome, if we could automatically pull out the exact commit which introduced exactly which failed build report in which module (and then as you mentioned, we probably need to notify both the author of the commit, and the maintainer of the effected module). If basically you want to ensure that each commit is buildable, the best way to do that is to have builders try *queued patches*, not just master. this is what the try server at Mozilla does: https://wiki.mozilla.org/ReleaseEngineering/TryServer the try server is a *great* tool (even if, sadly, is affected by Mercurial being arse) and it makes contributing code much, much safer. the try server can also be told to send the result of a patch set straight to a bug, so that the build status and the test suite result is recorded along with the bug. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
steam games
So, I've started playing games on Steam and started filing bugs on the limited number of games that I own. I would like to encourage others to do the same. It might even be worth purchasing a steam game account so that we can purchase problematic games for testing. It seems to me that having Steam games working under GNOME 3 in a fast and reliable manner should be tracked. As, games is one of the primary attraction to a desktop I think it might be worth tracking specifically. What do people think about this? If there is agreement what would be a good way to track? Worth having a GNOME Goal to track this? sri ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Most compatible AND useful toolkit for use in GNOME
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13-02-13 02:44 PM, Marco Scannadinari wrote: Hi, Hi! What are your recommendations for a toolkit that is best suited to GNOME app development (obviously GTK+3), but also useful in developing apps for other distros / OSs - I feel that the general suggestion is Qt. Qt is an entirely unrelated toolkit, it has nothing to do with Gtk. Others have said even wxWidgets, because it draws native widgets according to the environment. That is true, wxwidgets does allow your application to look like a native application between OSX, windows, and Gtk, and Qt. The problem with wxwidgets is that it is a subset of all systems, so you don't get the full power of Gtk, you just get a small subset of it, and it's somewhat limiting. Keep in mind my language of choice is python (3) and am quite new to graphical app development. Well if you want to write applications for GNOME, you should use Gtk: https://python-gtk-3-tutorial.readthedocs.org/en/latest/index.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJRHCVvAAoJEMnVpoCaWglEV8YQAJiFHge4H4lzO4MtPTAmDHDN jKxHlwLrOYxRACGOmQqateIYAjjvfrCmDq4BfUZBjtkEAhdBoi0Zy2x016ICpea6 zEK/UAQyKVVjdQ8ZIQeKZoDuqQgiDC5Rt8hudPmpX+rCnJeU+VhU1cWg/IK3n7PY oE7bAobzc7U2u0USEqLaFEZbn3VlIqNKN+hQG5nKf2BNSjbItmkV2b6Ighnji5J4 r6oIO015X1d83aI/80q2KbisKTzBChZ1nkOlmTUHEfBryU1UniItYXtDWrvpydec yHSjop2wiOZi10FFuvhmkWGalj18evIgRjvQ8FXdwaVnf/HMwGhqGopKDdlIhM3G er4mQxSkuJMDj57EdtUkAdcZWqjuUtCSozfBd2bgviNYIoegecB3otApbztKj8d6 733q9G+hzwonyvyU52HG6K24SHT3xOl+LdaVpxlAuN/wf1fbjV/sgDVGnkRM7XSz PyUeRswyrvk5RaXbgAgBi6HWhCdYiszRGzuljamrzekfkI+o+TekJsZu6dhrgf7S BipcBPK7z4cgjf2iE3JJjiMy1fi0Pj+gBwUwXov3mVk2YJCrQqBHSauuxHnV2fjD oWZ8bEIpCcefjqViVDTEv74IkbNZeY0AEIDbhnvjnyK4EyujlZ9hHO2KHGWXu4VJ 3kmb3hTbpRWvvHeNaYlv =0Fbz -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: steam games
I think that it'd be more interesting to engage with Valve to know how the GNOME platform could help steam get a better product. It is an interesting ISV usecase. 2013/2/13 Sriram Ramkrishna s...@ramkrishna.me: So, I've started playing games on Steam and started filing bugs on the limited number of games that I own. I would like to encourage others to do the same. It might even be worth purchasing a steam game account so that we can purchase problematic games for testing. It seems to me that having Steam games working under GNOME 3 in a fast and reliable manner should be tracked. As, games is one of the primary attraction to a desktop I think it might be worth tracking specifically. What do people think about this? If there is agreement what would be a good way to track? Worth having a GNOME Goal to track this? sri ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Cheers, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: steam games
I can get a contact, I think. I'll ask for permission to contact them. sri On Wed, Feb 13, 2013 at 4:18 PM, Alberto Ruiz ar...@gnome.org wrote: I think that it'd be more interesting to engage with Valve to know how the GNOME platform could help steam get a better product. It is an interesting ISV usecase. 2013/2/13 Sriram Ramkrishna s...@ramkrishna.me: So, I've started playing games on Steam and started filing bugs on the limited number of games that I own. I would like to encourage others to do the same. It might even be worth purchasing a steam game account so that we can purchase problematic games for testing. It seems to me that having Steam games working under GNOME 3 in a fast and reliable manner should be tracked. As, games is one of the primary attraction to a desktop I think it might be worth tracking specifically. What do people think about this? If there is agreement what would be a good way to track? Worth having a GNOME Goal to track this? sri ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Cheers, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcement/RFC: jhbuild continuous integration testing
Hello Tristan, Tristan Van Berkom [2013-02-14 6:42 +0900]: Upon reading this particular part (and I noticed before you are using mostly jhbuild mechanics), it leads me to wonder, how granular exactly are these rebuilds ? Right now, every 15 minutes. Sometimes longer, when the previous run is still running. I think ideally it would be great if builds could be triggered by commit. In other words, commits are serialized chronologically and each and every commit should trigger an entire rebuild, each rebuild should build everything in the moduleset up to the latest commit... separately, one after the other. That is indeed the long-term plan, but there's still some work to be done before we can do that. The machine we are running this on has 64 2.7 GHz cores and 64 GB of RAM, that really isn't a bottleneck right now. The main two problems right now are that the jhbuild update stage takes some 5 minutes to update all the ~ 160 git trees, and that jhbuild build doesn't parallelize at all, i. e. build modules which don't depend on each other could build in parallel. Once we solve both, and we dramatically reduce the time of one run from several hours (which is currently needed if e. g. a glib change happens, which rebuilds pretty much everything) to 15 minutes. The way I imagine this works now (and this is a big assumption, correct me if I'm wrong), is that a commit in a given module triggers a jhbuild build, which would mean that: a.) Several commits could have been made in a given module by the time jhbuild actually runs... meaning we dont know which of the given commits in that lapse of time actually caused the fault. That's right. It's massively better to know that one commit in these 15 minutes triggered it than something in the past week, but still not perfect as you say. b.) Module foo triggers a rebuild... and while jhbuild builds, it also pulls in new changes from module bar, in this case it's possible that a recent commit in module bar caused another module baz to be effected, but in the end it's module foo who is blamed (since module foo essentially /triggered a rebuild/) That's a trickier thing. For most commits, one should actually be able to build them independently, but sometimes those in between breaks are inevitable. Say, you make an API change in a library and then update your application to the new API, then in between you will get a build failure. The next iteration should fix it again. We have that problem independently of the frequency we build stuff of course, as we can always hit a bad time. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcement/RFC: jhbuild continuous integration testing
Hello again,
first, thanks for everyone who jumped in and helped to fix failures! I
wanted to send a quick update.
Martin Pitt [2013-02-12 7:43 +0100]:
- colord: recently started depending on libsystemd-login, which we
don't have yet; that's a fault on the Ubuntu side
I installed the libsystemd-login libs and pushed a fix for a missing
library link to trunk. Working now.
- e-d-s: calls an undeclared g_cond_timed_wait(), not sure what this
is about
I filed a bug, Matthew Barnes quickly fixed it in trunk. After that it
was working for two runs. (Not any more, see below)
- folks: this started failing very recently, and thus is a perfect
example why this is useful (unqualified ambiguous usage of
HashTable)
Philip quickly fixed that one, working now.
- 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
Still outstanding.
- 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
Jasper pointed out the problem in Ubuntu'x libxi packages, I'll take
care of this.
Test failures:
- gst-plugins-good, empathy: one test failure, the other tests work
gst-plugins-good got fixed by Tim, empathy still outstanding.
- 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
Still outstanding.
So yesterday evening we were down to 5 failures, but over night we got
a swath of new test failures. Wading through them now, but some look
quite nonobvious.
nautilus failed on
evaluated: nautilus_file_get_name (file_1)
expected: eazel:///
got: eazel:
It failed on exactly that until January 5, then was working until
yesterday, and now failing again. For such issues I'd be glad if one
of the nautilus maintainers could work this out with me.
libgdata once again failed on the youtube test, as it did in the past.
In general, any test that tries to access remote servers is pretty
much doomed on that machine I'm afraid, as it can only do http and
https through a proxy (it has $http{,s}_proxy set).
I'll look at the other failures now.
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
signature.asc
Description: Digital signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
