Re: [Python-Dev] buildbots
Hi and thanks for your answers, > If you are able to offer something that's not on the list, that'd be > good. But any help at all is appreciated. > > I believe Windows has traditionally been under-represented in all > buildbot farms, and it's likely to stay that way... Well what I could provide is a 32-bit x86 Debian stable. Rather common I fear... > For Pybots, we're testing third-party apps and libraries against > changes made to Python core. If you're interested in a 3rd party > project, and you're willing to stay on top of that project's buildbot > status, and notify both the project leaders and the Python core devs > whenever you notice an ugly breakage Not interested /enough/ I think... by your description it sounds the job should really be done by a core developer of each of those packages (even if the machine is donated by someone else). What I could be interested in is to provide a buildbot for Python itself, but I don't know if that's needed right now. Especially for such a common platform as a x86 Debian. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] buildbot failure in sparc Debian 3.0
Does anyone have a clue about why this test fails only on this
platform? The test is question is verifying that URLError gets
raised. From the traceback, it appears that there is an uncaught
exception (URLError) but it fails in an assertRaises() check for
URLError. That doesn't make much sense unless the variable URLError
refers to different objects, but both modules use "from urllib.error
import URLError". And, of course, the test works fine on other
platforms.
Jeremy
On Wed, Jul 2, 2008 at 4:23 PM, <[EMAIL PROTECTED]> wrote:
> The Buildbot has detected a new failure of sparc Debian 3.0.
> Full details are available at:
> http://www.python.org/dev/buildbot/all/sparc%20Debian%203.0/builds/330
>
> Buildbot URL: http://www.python.org/dev/buildbot/all/
>
> Buildslave for this Build: klose-debian-sparc
>
> Build Reason:
> Build Source Stamp: [branch branches/py3k] HEAD
> Blamelist: benjamin.peterson
>
> BUILD FAILED: failed test
>
> Excerpt from the test logfile:
> 1 test failed:
>test_urllib2
>
> ==
> ERROR: test_badly_named_methods (test.test_urllib2.OpenerDirectorTests)
> --
>
> Traceback (most recent call last):
> File
> "/home/pybot/buildarea-sid/3.0.klose-debian-sparc/build/Lib/test/test_urllib2.py",
> line 408, in test_badly_named_methods
>self.assertRaises(URLError, o.open, scheme+"://example.com/")
> File
> "/home/pybot/buildarea-sid/3.0.klose-debian-sparc/build/Lib/unittest.py",
> line 311, in failUnlessRaises
>callableObj(*args, **kwargs)
> File
> "/home/pybot/buildarea-sid/3.0.klose-debian-sparc/build/Lib/urllib/request.py",
> line 356, in open
>response = self._open(req, data)
> File
> "/home/pybot/buildarea-sid/3.0.klose-debian-sparc/build/Lib/urllib/request.py",
> line 379, in _open
>'unknown_open', req)
> File
> "/home/pybot/buildarea-sid/3.0.klose-debian-sparc/build/Lib/urllib/request.py",
> line 334, in _call_chain
>result = func(*args)
> File
> "/home/pybot/buildarea-sid/3.0.klose-debian-sparc/build/Lib/urllib/request.py",
> line 1102, in unknown_open
>raise URLError('unknown url type: %s' % type)
> urllib.error.URLError:
>
> make: *** [buildbottest] Error 1
>
> sincerely,
> -The Buildbot
>
> ___
> Python-checkins mailing list
> [EMAIL PROTECTED]
> http://mail.python.org/mailman/listinfo/python-checkins
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] buildbot failure in sparc Debian 3.0
Jeremy Hylton wrote: > Does anyone have a clue about why this test fails only on this > platform? The test is question is verifying that URLError gets > raised. From the traceback, it appears that there is an uncaught > exception (URLError) but it fails in an assertRaises() check for > URLError. That doesn't make much sense unless the variable URLError > refers to different objects, but both modules use "from urllib.error > import URLError". And, of course, the test works fine on other > platforms. It might be a transient error, and a complete cleanup of the tree might fix it. To do so, build a non-existent branch through the web ui, then build the original branch again; this will cause a fresh checkout. If the error then persists, my guess it's some kind of compiler issue, which can be investigated only with access to the machine. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Community buildbots and Python release quality metrics
On 6 Jul, 05:29 pm, [EMAIL PROTECTED] wrote: (I'd also like to improve the labels of the build slaves. What exactly is "x86 Red Hat 9 trunk" testing? Trunk of what? What project?) It seems like you would like to edit the master configuration file. That can be arranged fairly easily. How shall we arrange it, then? :) Whoever is interested, I've got a recent SSH key on https://launchpad.net/~glyph/+sshkeys ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Community buildbots and Python release quality metrics
On 6 Jul, 09:09 pm, [EMAIL PROTECTED] wrote: On Sun, Jul 6, 2008 at 8:46 AM, <[EMAIL PROTECTED]> wrote: It's one thing to tell people that they need to be helping out (and I'm sure you're right) but it's much more useful to get the message out that "we really need people to do X, Y, and Z". I have posted 'cries for help' repeatedly on my blog, with generally little success. See http://agiletesting.blogspot.com/search?q=pybots . But I will post again. If you can include here a paragraph of what your vision of the 'X, Y and Z' above is, that'd help too It looks to me like the main thing that Pybots needs is help with maintenance. Getting someone to set up an individual buildbot is one thing, but keeping it working is the important bit and it looks like people are not doing that. The project would also be greatly aided by having dedicated people diagnose errors, report bugs against Python core if they're real and report bugs against Pybots if they're spurious. It would be good to have this effort be centralized and directed because it would otherwise be too easy to file duplicate bug reports, or to assume "oh, this has been failing for months, someone must have filed a bug already". It's not only a question of changing a static label in this case. A given buildslave can run the tests for multiple projects, in which case it becomes tricky to change the label on the fly accordingly. I'm a bit confused about how the projects being tested changes on the fly... but then, this level of specifics is probably best left to the pybots mailing list. Hopefully sometime soon I'll have the time to add yet another subscription. Thanks for cleaning up the buildbots though! I can see a lot more tests actually running now :). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Community buildbots and Python release quality metrics
On Tue, Jul 8, 2008 at 12:56 PM, <[EMAIL PROTECTED]> wrote: > It looks to me like the main thing that Pybots needs is help with > maintenance. Getting someone to set up an individual buildbot is one thing, > but keeping it working is the important bit and it looks like people are not > doing that. The project would also be greatly aided by having dedicated > people diagnose errors, report bugs against Python core if they're real and > report bugs against Pybots if they're spurious. > > It would be good to have this effort be centralized and directed because it > would otherwise be too easy to file duplicate bug reports, or to assume "oh, > this has been failing for months, someone must have filed a bug already". I agree with all you're saying here. As usual, the devil is in the details. Finding those 'dedicated people' and also people who would act as the central point of contact for bug reports etc. turns out to be very hard in practice. If you have any ideas, I'd be glad to hear them. Grig ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
