Considering that we've just released 2.7rc2, there are an awful lot of red buildbots for 2.7. In fact, I don't remember having seen a green buildbot for OS X and 2.7. Shouldn't these be fixed? On OS X Leopard, I'm seeing failures in test_py3kwarn, test_urllib2_localnet, test_uuid. On OS X Tiger, I'm seeing failures in test_pep277, test_py3kwarn, test_ttk_guionly, and test_urllib2_localnet. We don't have a buildbot running Snow Leopard, apparently. Bill
2010/6/21 Bill Janssen <janssen@parc.com>:
Considering that we've just released 2.7rc2, there are an awful lot of red buildbots for 2.7. In fact, I don't remember having seen a green buildbot for OS X and 2.7. Shouldn't these be fixed?
It seems most of them are off line and there last run was just a failure.
On OS X Leopard, I'm seeing failures in test_py3kwarn, test_urllib2_localnet, test_uuid.
On OS X Tiger, I'm seeing failures in test_pep277, test_py3kwarn, test_ttk_guionly, and test_urllib2_localnet.
File bug reports.
We don't have a buildbot running Snow Leopard, apparently.
-- Regards, Benjamin
Benjamin Peterson <benjamin@python.org> wrote:
2010/6/21 Bill Janssen <janssen@parc.com>:
Considering that we've just released 2.7rc2, there are an awful lot of red buildbots for 2.7. In fact, I don't remember having seen a green buildbot for OS X and 2.7. Shouldn't these be fixed?
It seems most of them are off line and there last run was just a failure.
No, the three OS X buildbots are all online and reporting failures. As far as I can remember, they haven't been green for weeks. They are at the end of the buildbot list, so off-screen if you are using a normal browser. You have to scroll to see them.
On OS X Leopard, I'm seeing failures in test_py3kwarn, test_urllib2_localnet, test_uuid.
On OS X Tiger, I'm seeing failures in test_pep277, test_py3kwarn, test_ttk_guionly, and test_urllib2_localnet.
Um -- saying what, the buildbots are red? Shouldn't having green buildbots be a part of the release process? In fact, it is -- but none of the OS X buildbots are part of the "stable" set. Why is that? Bill
On Mon, 21 Jun 2010 12:13:05 PDT Bill Janssen <janssen@parc.com> wrote:
On OS X Leopard, I'm seeing failures in test_py3kwarn, test_urllib2_localnet, test_uuid.
On OS X Tiger, I'm seeing failures in test_pep277, test_py3kwarn, test_ttk_guionly, and test_urllib2_localnet.
Um -- saying what, the buildbots are red? Shouldn't having green buildbots be a part of the release process? In fact, it is -- but none of the OS X buildbots are part of the "stable" set. Why is that?
Benjamin is not qualified to fix OS X bugs AFAIK (if you are, Benjamin, then sorry for misrepresenting you :-)). Actually, neither are most of us. Apparently some of these buildbots belong to you. Why don't you step up and investigate? Thanks, Antoine.
Antoine Pitrou <solipsis@pitrou.net> wrote:
Benjamin is not qualified to fix OS X bugs AFAIK (if you are, Benjamin, then sorry for misrepresenting you :-)). Actually, neither are most of us.
Right. I was thinking that the release manager should however be responsible for not releasing while there are red buildbots. But it's not his fault, either; there are no OS X buildbots on the "stable" list, and that's the list PEP 101 says to look at. The real problem here is that a major platform doesn't have a "stable" buildbot, I think. I've logged an issue to that effect.
Apparently some of these buildbots belong to you. Why don't you step up and investigate?
The fact that I'm running some buildbots doesn't mean I have to fix the problems that they reveal, I think. I did look at the py3kwarn failure, and couldn't figure out the various twisty passages of deprecation warning as further snarled by the test package. I think that one needs someone who's intimately familiar with the testing framework. Bill
Le lundi 21 juin 2010 à 12:57 -0700, Bill Janssen a écrit :
Apparently some of these buildbots belong to you. Why don't you step up and investigate?
The fact that I'm running some buildbots doesn't mean I have to fix the problems that they reveal, I think.
You certainly don't have to. But please don't ask others to do it for you, *especially* if the failure can't be reproduced under anything else than OS X, and if no useful diagnosis is available. Regards Antoine.
On 21/06/2010 21:02, Antoine Pitrou wrote:
Le lundi 21 juin 2010 à 12:57 -0700, Bill Janssen a écrit :
Apparently some of these buildbots belong to you. Why don't you step up and investigate?
The fact that I'm running some buildbots doesn't mean I have to fix the problems that they reveal, I think.
You certainly don't have to. But please don't ask others to do it for you, *especially* if the failure can't be reproduced under anything else than OS X, and if no useful diagnosis is available.
If OS X is a supported and important platform for Python then fixing all problems that it reveals (or being willing to) should definitely not be a pre-requisite of providing a buildbot (which is already a service to the Python developer community). Fixing bugs / failures revealed by Bill's buildbot is not fixing them "for Bill" it is fixing them for Python. All the best, Michael
Regards
Antoine.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.u...
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
Le lundi 21 juin 2010 à 21:13 +0100, Michael Foord a écrit :
If OS X is a supported and important platform for Python then fixing all problems that it reveals (or being willing to) should definitely not be a pre-requisite of providing a buildbot (which is already a service to the Python developer community). Fixing bugs / failures revealed by Bill's buildbot is not fixing them "for Bill" it is fixing them for Python.
I didn't say it was a prerequisite. I was merely pointing out that when platform-specific bugs appear, people using the specific platform should be helping if they want to actually encourage the fixing of these bugs. OS X is only "a supported and important platform" if we have dedicated core developers diagnosing or even fixing issues for it (like we obviously have for Windows and Linux). Otherwise, I don't think we have any moral obligation to support it. Regards Antoine.
Antoine Pitrou <solipsis@pitrou.net> wrote:
OS X is only "a supported and important platform" if we have dedicated core developers diagnosing or even fixing issues for it (like we obviously have for Windows and Linux). Otherwise, I don't think we have any moral obligation to support it.
Fair enough. That being said, there are two classes of OS X issues. The first is the kind of thing that Ronald Oussoren and Ned Deily keep fixing for us, which require a knowledge of OS X frameworks and SDKs and various other deeply-Apple oddnesses. But the second class is a set of UNIX issues, where OS X is just a variant of UNIX with minor differences from other UNIX platforms. It looks to me as if we don't really need Apple geeks for the second class of issues, we just need developers who have a Mac to test on. It looks to me, for instance, as if the failures in test_py3kwarn and test_uuid on Leopard are bugs in the Python testing framework that happen to be exercised on OS X, rather than bugs caused in some way by the platform. There, the requisite knowledge is, how does regrtest.py really work? Bill
On 21 Jun, 2010, at 22:25, Antoine Pitrou wrote:
Le lundi 21 juin 2010 à 21:13 +0100, Michael Foord a écrit :
If OS X is a supported and important platform for Python then fixing all problems that it reveals (or being willing to) should definitely not be a pre-requisite of providing a buildbot (which is already a service to the Python developer community). Fixing bugs / failures revealed by Bill's buildbot is not fixing them "for Bill" it is fixing them for Python.
I didn't say it was a prerequisite. I was merely pointing out that when platform-specific bugs appear, people using the specific platform should be helping if they want to actually encourage the fixing of these bugs.
OS X is only "a supported and important platform" if we have dedicated core developers diagnosing or even fixing issues for it (like we obviously have for Windows and Linux). Otherwise, I don't think we have any moral obligation to support it.
I look into and fix OSX issues, but do so in my spare time. This means it can take a while until I get around doing so. Ronald P.S. Please file bugs for issues on OSX and set the compontent to Macintosh instead of discussing them on python-dev. I don't read python-dev on a daily basis almost missed this thread.
If OS X is a supported and important platform for Python then fixing all problems that it reveals (or being willing to) should definitely not be a pre-requisite of providing a buildbot (which is already a service to the Python developer community). Fixing bugs / failures revealed by Bill's buildbot is not fixing them "for Bill" it is fixing them for Python.
I wish people would stop using the word "supported" when they talk about free software. *No* system is "supported" by Python - not even in the sense "we strive to pass the test suite". "We" don't. Now, one may argue whether failing buildbots should be an unconditional reason to defer the release. I personally would say "no", despite what some PEP may say. People proposing that a release is postponed typically hope that somebody gets frustrated enough to step up and fix the bug, just so that the software gets released. Instead, I would propose that the only way to delay a release is by proposing to take some specific action to remedy the situation that should cause the delay. Otherwise, releasing is at the discretion of the release manager, who has the ultimate say to whether the problem is important or not. As for OSX, it seems that the only test that is failing is the ctypes test suite, and there only a single test. I don't think this is sufficient reason to block the release. Regards, Martin
On 21/06/2010 22:12, "Martin v. Löwis" wrote:
If OS X is a supported and important platform for Python then fixing all problems that it reveals (or being willing to) should definitely not be a pre-requisite of providing a buildbot (which is already a service to the Python developer community). Fixing bugs / failures revealed by Bill's buildbot is not fixing them "for Bill" it is fixing them for Python.
I wish people would stop using the word "supported" when they talk about free software. *No* system is "supported" by Python - not even in the sense "we strive to pass the test suite". "We" don't.
Well, for better or for worse I think "we" do. We certainly *strive* to support these platforms and having the buildbots is a big part of this.
Now, one may argue whether failing buildbots should be an unconditional reason to defer the release. I personally would say "no", despite what some PEP may say. People proposing that a release is postponed typically hope that somebody gets frustrated enough to step up and fix the bug, just so that the software gets released.
Instead, I would propose that the only way to delay a release is by proposing to take some specific action to remedy the situation that should cause the delay. Otherwise, releasing is at the discretion of the release manager, who has the ultimate say to whether the problem is important or not.
I would agree with leaving it to the discretion of the release manager and we should aim for rather than hard require all stable buildbots to be green. I would still *expect* that a release manager would look at the stable buildbots before cutting a release.
As for OSX, it seems that the only test that is failing is the ctypes test suite, and there only a single test. I don't think this is sufficient reason to block the release.
Bill listed several other failures he saw on the buildbots and I see the same set, plus test_posix. All the best, Michael
Regards, Martin
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
Bill listed several other failures he saw on the buildbots and I see the same set, plus test_posix.
Still, the question would be whether any of these failures can manage to block a release. Are they regressions from 2.6? That would make them good candidates for release blockers. Except that I still would like to see commitment from somebody to fix them or else they can't block the release: if "we" don't mean that supporting a platform also means volunteering to fix bugs, then I guess "we" should stop declaring the platform supported. Just wishing that it was supported actually doesn't make it so. If the test failure *isn't* a regression, I think it shouldn't block the release. Regards, Martin
On 21/06/2010 22:36, "Martin v. Löwis" wrote:
Bill listed several other failures he saw on the buildbots and I see the same set, plus test_posix.
Still, the question would be whether any of these failures can manage to block a release. Are they regressions from 2.6?
The test_posix failure is a regression from 2.6 (but it only shows up on some machines - it is caused by a fairly braindead implementation of a couple of posix apis by Apple apparently). http://bugs.python.org/issue7900 There are various patches available and a lot of work that has gone into diagnosing it - but there was some disagreement on what is the *best* way to fix it. Two of the other failures I'm pretty sure are problems in the test suite rather than bugs (as Bill said) and I'm not sure about the ctypes issue. Just starting a full build here. Michael
That would make them good candidates for release blockers. Except that I still would like to see commitment from somebody to fix them or else they can't block the release: if "we" don't mean that supporting a platform also means volunteering to fix bugs, then I guess "we" should stop declaring the platform supported. Just wishing that it was supported actually doesn't make it so.
If the test failure *isn't* a regression, I think it shouldn't block the release.
Regards, Martin
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On 21/06/2010 22:52, Michael Foord wrote:
On 21/06/2010 22:36, "Martin v. Löwis" wrote:
Bill listed several other failures he saw on the buildbots and I see the same set, plus test_posix.
Still, the question would be whether any of these failures can manage to block a release. Are they regressions from 2.6?
The test_posix failure is a regression from 2.6 (but it only shows up on some machines - it is caused by a fairly braindead implementation of a couple of posix apis by Apple apparently).
http://bugs.python.org/issue7900
There are various patches available and a lot of work that has gone into diagnosing it - but there was some disagreement on what is the *best* way to fix it.
Two of the other failures I'm pretty sure are problems in the test suite rather than bugs (as Bill said) and I'm not sure about the ctypes issue. Just starting a full build here.
Right now I'm *only* seeing these two failures on Mac OS X (10.6.4): test_posix test_urllib2_localnet All the best, Michael
Michael
That would make them good candidates for release blockers. Except that I still would like to see commitment from somebody to fix them or else they can't block the release: if "we" don't mean that supporting a platform also means volunteering to fix bugs, then I guess "we" should stop declaring the platform supported. Just wishing that it was supported actually doesn't make it so.
If the test failure *isn't* a regression, I think it shouldn't block the release.
Regards, Martin
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On 21 June 2010 22:57, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
Two of the other failures I'm pretty sure are problems in the test suite rather than bugs (as Bill said) and I'm not sure about the ctypes issue. Just starting a full build here.
Right now I'm *only* seeing these two failures on Mac OS X (10.6.4):
test_posix test_urllib2_localnet
I'm still seeing a test_ctypes failure (on Windows XP). Not sure if it's the same one Bill was seeing: FAIL: test_issue_8959_b (ctypes.test.test_callbacks.SampleCallbacksTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\buildslave\trunk.moore-windows\build\lib\ctypes\test\test_callbacks.py", line 208, in test_issue_8959_b self.assertFalse(windowCount == 0) AssertionError: True is not False Looks like this test was added today, and counts the windows. As my buildbot is running as a service, and I generally leave it running when logged off, a window count of 0 may well be correct - I can't be sure. So my view is that it's possibly a bug in the test - but it could do with someone more expert to confirm this. I've got a build running at the moment, when it's finished I'll rerun the trunk build (I currently have a disconnected session with a window open, I'll see if that makes it pass). Paul.
On 21 June 2010 23:19, Paul Moore <p.f.moore@gmail.com> wrote:
On 21 June 2010 22:57, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
Two of the other failures I'm pretty sure are problems in the test suite rather than bugs (as Bill said) and I'm not sure about the ctypes issue. Just starting a full build here.
Right now I'm *only* seeing these two failures on Mac OS X (10.6.4):
test_posix test_urllib2_localnet
I'm still seeing a test_ctypes failure (on Windows XP). Not sure if it's the same one Bill was seeing:
FAIL: test_issue_8959_b (ctypes.test.test_callbacks.SampleCallbacksTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\buildslave\trunk.moore-windows\build\lib\ctypes\test\test_callbacks.py", line 208, in test_issue_8959_b self.assertFalse(windowCount == 0) AssertionError: True is not False
Looks like this test was added today, and counts the windows. As my buildbot is running as a service, and I generally leave it running when logged off, a window count of 0 may well be correct - I can't be sure. So my view is that it's possibly a bug in the test - but it could do with someone more expert to confirm this.
I've got a build running at the moment, when it's finished I'll rerun the trunk build (I currently have a disconnected session with a window open, I'll see if that makes it pass).
Yes, looks like it's a bug in the test. http://bugs.python.org/issue9055 raised. Paul.
On Mon, Jun 21, 2010 at 6:39 PM, Paul Moore <p.f.moore@gmail.com> wrote: ..
Yes, looks like it's a bug in the test. http://bugs.python.org/issue9055 raised.
I concur. I've updated the issue with a proposed fix. (The problem is that proxy host names should have a '.' in them on OSX.) I am trying to decide whether the fix should be applied for all platforms or conditionally for darwin. Can someone test the fix on Windows?
Oh, I thought that was about http://bugs.python.org/issue8455 . On Mon, Jun 21, 2010 at 9:05 PM, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
On Mon, Jun 21, 2010 at 6:39 PM, Paul Moore <p.f.moore@gmail.com> wrote: ..
Yes, looks like it's a bug in the test. http://bugs.python.org/issue9055 raised.
I concur. I've updated the issue with a proposed fix. (The problem is that proxy host names should have a '.' in them on OSX.) I am trying to decide whether the fix should be applied for all platforms or conditionally for darwin. Can someone test the fix on Windows?
Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
Oh, I thought that was about http://bugs.python.org/issue8455 .
On Mon, Jun 21, 2010 at 9:05 PM, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
On Mon, Jun 21, 2010 at 6:39 PM, Paul Moore <p.f.moore@gmail.com> wrote: ..
Yes, looks like it's a bug in the test. http://bugs.python.org/issue9055 raised.
I concur. I've updated the issue with a proposed fix. (The problem is that proxy host names should have a '.' in them on OSX.) I am trying to decide whether the fix should be applied for all platforms or conditionally for darwin. Can someone test the fix on Windows?
Ah, thanks for tracking that one down. I'll bet it's the same problem I'm seeing with proxy authentication with bad credentials unexpectedly succeeding. Though, isn't that behavior of urllib.proxy_bypass another bug? Bill
Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
On Mon, Jun 21, 2010 at 9:26 PM, Bill Janssen <janssen@parc.com> wrote: ..
Though, isn't that behavior of urllib.proxy_bypass another bug?
I don't know. Ask Ronald.
Hmmm. I brought up the System Preferences panel on my Mac, and sure enough, there's a checkbox, "Exclude simple hostnames". So I guess it's not a bug, though none of my Macs are configured that way. Bill
The test_posix failure is a regression from 2.6 (but it only shows up on some machines - it is caused by a fairly braindead implementation of a couple of posix apis by Apple apparently).
Ah, that one. I definitely think this should *not* block the release: a) there is no clear solution in sight. So if we wait for it resolved, it could take months until we get a 2.7 release. b) it's only about getgroups - a fairly minor API. c) IIUC, it only occurs to users which are member of more than 16 groups - a fairly uncommon setup. Regards, Martin
On Mon, Jun 21, 2010 at 6:16 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
The test_posix failure is a regression from 2.6 (but it only shows up on some machines - it is caused by a fairly braindead implementation of a couple of posix apis by Apple apparently).
Ah, that one. I definitely think this should *not* block the release:
I agree that this is nowhere near being a release blocker, but I think it would be nice to do something about it before the final release.
a) there is no clear solution in sight. So if we wait for it resolved, it could take months until we get a 2.7 release.
The ideal solution will have to wait until Apple gets its act together and fixed the problem on their end. I would say "months" is an overly optimistic time estimate for that. However, the issue is a regression from prior versions. In 2.5 getgroups would truncate the list to 16 groups, but won't crash. More importantly the 16 groups returned would be correct per-process groups and not something immune to setgroup changes. I proposed a very simple fix: http://bugs.python.org/file16326/no-darwin-ext.diff which simply minimally reverts the change that introduced the regression.
b) it's only about getgroups - a fairly minor API.
Agree, but failing regression test is an annoyance particularly in this case where the diagnostic from the test is very vague. Short of fixing the problem, we can skip the failing test on OSX if getgroups raises exception.
c) IIUC, it only occurs to users which are member of more than 16 groups - a fairly uncommon setup.
Unfortunately it is fairly common. The default root account on OSX is member of 18 groups. Given that many os tests require root privileges, people will run these tests as root.
On 22 Jun, 2010, at 3:38, Alexander Belopolsky wrote:
On Mon, Jun 21, 2010 at 6:16 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
The test_posix failure is a regression from 2.6 (but it only shows up on some machines - it is caused by a fairly braindead implementation of a couple of posix apis by Apple apparently).
Ah, that one. I definitely think this should *not* block the release:
I agree that this is nowhere near being a release blocker, but I think it would be nice to do something about it before the final release.
a) there is no clear solution in sight. So if we wait for it resolved, it could take months until we get a 2.7 release.
The ideal solution will have to wait until Apple gets its act together and fixed the problem on their end. I would say "months" is an overly optimistic time estimate for that.
I'd say there is no chance at all that this will be fixed in OSX 10.6, with some luck they'll change this in 10.7.
However, the issue is a regression from prior versions. In 2.5 getgroups would truncate the list to 16 groups, but won't crash. More importantly the 16 groups returned would be correct per-process groups and not something immune to setgroup changes.
I proposed a very simple fix:
http://bugs.python.org/file16326/no-darwin-ext.diff
which simply minimally reverts the change that introduced the regression.
That is one way to fix it, another just as valid fix is to change posix.getgroups to be able to return more than 16 groups on OSX (see my patch in issue7900). Both are valid fixes, both have both advantages and disadvantages. Your proposal: * Reverts to the behavior in 2.6 * Ensures that posix.getgroups and posix.setgroups are internally consistent My proposal: * Uses the newer ABI, which is more likely to be the one Apple wants you to use * Is compatible with system tools (that is, posix.getgroups() agrees with id(1)) * Is compatible with /usr/bin/python * results in posix.getgroups not reflecting results of posix.setgroups What I haven't done yet, and probably should, is to check how either implementation of getgroups interacts with groups in the System Preferences panel and with groups in managed environment (using OSX Server). My gut feeling is that second option (my proposal) would give more useful semantics, but that said: I almost never write code where I need os.setgroups. Ronald
On Tue, Jun 22, 2010 at 12:39 PM, Ronald Oussoren <ronaldoussoren@mac.com> wrote: ..
Both are valid fixes, both have both advantages and disadvantages.
Your proposal: * Reverts to the behavior in 2.6 * Ensures that posix.getgroups and posix.setgroups are internally consistent
It is also very simple and since posix module worked fine on OSX for years without _DARWIN_C_SOURCE, I think this is a very low risk change.
My proposal: * Uses the newer ABI, which is more likely to be the one Apple wants you to use
I don't think so. In getgroups(2) I see LEGACY DESCRIPTION If _DARWIN_C_SOURCE is defined, getgroups() can return more than {NGROUPS_MAX} groups. This suggests that this is legacy behavior. Newer applications should use getgrouplist instead.
* Is compatible with system tools (that is, posix.getgroups() agrees with id(1))
I have not tested this recently, but I think if you exec id from a program after a call to setgroups(), it will return process groups, not user groups.
* Is compatible with /usr/bin/python
I am sure that one this issue is fixed upstream, Apple will pick it up with the next version.
* results in posix.getgroups not reflecting results of posix.setgroups
This effectively substitutes getgrouplist called on the current user for getgroups. In 3.x, I believe the correct action will be to provide direct access to getgrouplist which is while not POSIX (yet?), is widely available.
This effectively substitutes getgrouplist called on the current user for getgroups. In 3.x, I believe the correct action will be to provide direct access to getgrouplist which is while not POSIX (yet?), is widely available.
As a policy, adding non-POSIX functions to the posix module is perfectly fine, as long as there is an autoconf test for it (plain ifdefs are gruntingly accepted also). Regards, Martin
On 22 Jun, 2010, at 19:05, Alexander Belopolsky wrote:
On Tue, Jun 22, 2010 at 12:39 PM, Ronald Oussoren <ronaldoussoren@mac.com> wrote: ..
Both are valid fixes, both have both advantages and disadvantages.
Your proposal: * Reverts to the behavior in 2.6 * Ensures that posix.getgroups and posix.setgroups are internally consistent
It is also very simple and since posix module worked fine on OSX for years without _DARWIN_C_SOURCE, I think this is a very low risk change.
I don't agree. The patch itself is pretty simple, but it does make a rather significant change to the build process: the compile-time environment in configure would be different than during the compilation of posixmodule. That is, in functions that check for features (the HAVE_FOOBAR macros in pyconfig.h) would use _DARWIN_C_SOURCE while posixmodule itself wouldn't. This may lead to subtle bugs, or even compile errors (because some function definitions change when _DARWIN_C_SOURCE active). And man compat(5) says: <quote> 32-BIT COMPILATION Defining _NONSTD_SOURCE causes library and kernel calls to behave as closely to Mac OS X 10.3's library and kernel calls as possible. Any behavioral changes in this mode are documented in the LEGACY sections of the individual function calls. Defining _POSIX_C_SOURCE or _DARWIN_C_SOURCE causes library and kernel calls to conform to the SUSv3 standards even if doing so would alter the behavior of functions used in 10.3. Defining _POSIX_C_SOURCE also removes functions, types, and other interfaces that are not part of SUSv3 from the normal C namespace, unless _DARWIN_C_SOURCE is also defined (i.e., _DARWIN_C_SOURCE is _POSIX_C_SOURCE with non-POSIX exten- sions). In any of these cases, the _DARWIN_FEATURE_UNIX_CONFORMANCE feature macro will be defined to the SUS conformance level (it is unde- fined otherwise). Starting in Mac OS X 10.5, if none of the macros _NONSTD_SOURCE, _POSIX_C_SOURCE or _DARWIN_C_SOURCE are defined, and the environment vari- able MACOSX_DEPLOYMENT_TARGET is either undefined or set to 10.5 or greater (or equivalently, the gcc(1) option -mmacosx-version-min is either not specified or set to 10.5 or greater), then UNIX conformance will be on by default, and non-POSIX extensions will also be available (this is the equivalent of defining _DARWIN_C_SOURCE). For version values less that 10.5, UNIX conformance will be off (the equivalent of defining _NONSTD_SOURCE). </quote> My interpretation of that is that _DARWIN_C_SOURCE should be used to get SUSv3 APIs while keeping access to darwin-specific API's at well. When you deploy to 10.5 or later the compiler will set _DARWIN_C_SOURCE for you unless you set one of the other feature selecting defines.
My proposal: * Uses the newer ABI, which is more likely to be the one Apple wants you to use
I don't think so. In getgroups(2) I see
LEGACY DESCRIPTION If _DARWIN_C_SOURCE is defined, getgroups() can return more than {NGROUPS_MAX} groups.
This suggests that this is legacy behavior. Newer applications should use getgrouplist instead.
I honestly don't know why this is in the LEGACY DESCRIPTION. But as the functionality you get with _DARWIN_C_SOURCE was added later I'd say that the behavior is intentional and not legacy. By not definining _DARWIN_C_SOURCE we don't necessarily get full UNIX behavior for other APIs.
* Is compatible with system tools (that is, posix.getgroups() agrees with id(1))
I have not tested this recently, but I think if you exec id from a program after a call to setgroups(), it will return process groups, not user groups.
* Is compatible with /usr/bin/python
I am sure that one this issue is fixed upstream, Apple will pick it up with the next version.
Haha. Apple explicitly added patches to get the current behavior instead of the default, what makes you think that they'll revert to the older behavior.
* results in posix.getgroups not reflecting results of posix.setgroups
This effectively substitutes getgrouplist called on the current user for getgroups. In 3.x, I believe the correct action will be to provide direct access to getgrouplist which is while not POSIX (yet?), is widely available.
I don't mind adding getgrouplist, but that issue is seperator from this one. BTW. Appearently getgrouplist is posix (<http://refspecs.freestandards.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generi...>), although this isn't a requirement for being added to the posix module. It is still my opinion that the second option is preferable for better compatibility with system tools, even if the patch is more complicated and the library function we use can be considered to be broken. Ronald
On Wed, Jun 23, 2010 at 2:08 AM, Ronald Oussoren <ronaldoussoren@mac.com> wrote: ..
I don't agree. The patch itself is pretty simple, but it does make a rather significant change to the build process: the compile-time environment in configure would be different than during the compilation of posixmodule. That is, in functions that check for features (the HAVE_FOOBAR macros in pyconfig.h) would use _DARWIN_C_SOURCE while posixmodule itself wouldn't. This may lead to subtle bugs, or even compile errors (because some function definitions change when _DARWIN_C_SOURCE active).
I agree. Messing with compatibility macros outside of pyconfig.h is not a good idea. Martin's hack, while likely to work in most cases, is still a hack. I believe, however we can undefine _DARWIN_C_SOURCE globally at least on 10.4 and higher. I grepped throught the headers on my 10.6 system and I notice that the majority of checks for _DARWIN_C_SOURCE are in the form of #if !defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE) According to a comment in configure, # On Mac OS X 10.4, defining _POSIX_C_SOURCE or _XOPEN_SOURCE # disables platform specific features beyond repair. # On Mac OS X 10.3, defining _POSIX_C_SOURCE or _XOPEN_SOURCE # has no effect, don't bother defining them _POSIX_C_SOURCE is already undefined in python headers, so undefining _DARWIN_C_SOURCE will have no effect on the majority of checks. I was able to find very few exceptions: some cases check _XOPEN_SOURCE instead or in addition to _POSIX_C_SOURCE before ignoring _DARWIN_C_SOURCE: /usr/include/grp.h:#if !defined(_XOPEN_SOURCE) || defined(_DARWIN_C_SOURCE) /usr/include/pwd.h:#if (!defined(_POSIX_C_SOURCE) && !defined(_XOPEN_SOURCE)) || defined(_DARWIN_C_SOURCE) .. Since _XOPEN_SOURCE is similarly undefined in python headers, these cases are unaffected as well. This leaves a handful of cases where Apple provides additional macros for fine grained control: /usr/include/stdio.h:#if defined(__DARWIN_10_6_AND_LATER) && (defined(_DARWIN_UNLIMITED_STREAMS) || defined(_DARWIN_C_SOURCE)) /usr/include/unistd.h:#if defined(_DARWIN_UNLIMITED_GETGROUPS) || defined(_DARWIN_C_SOURCE) The second line above is our dear friend and the _DARWIN_C_SOURCE behavior conditioned on the first line can be enabled by defining _DARWIN_UNLIMITED_STREAMS macro. I believe _DARWIN_C_SOURCE casts its net to wide and more targeted macros should be used instead. ..
Defining _POSIX_C_SOURCE or _DARWIN_C_SOURCE causes library and kernel calls to conform to the SUSv3 standards even if doing so would alter the behavior of functions used in 10.3.
I cannot reconcile this with !defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE) logic that I see in the headers.
On 23 Jun, 2010,at 04:06 PM, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote: On Wed, Jun 23, 2010 at 2:08 AM, Ronald Oussoren <ronaldoussoren@mac.com> wrote: ..
I don't agree. The patch itself is pretty simple, but it does make a rather significant change to the build process: the compile-time environment in configure would be different than during the compilation of posixmodule. That is, in functions that check for features (the HAVE_FOOBAR macros in pyconfig.h) would use _DARWIN_C_SOURCE while posixmodule itself wouldn't. This may lead to subtle bugs, or even compile errors (because some function definitions change when _DARWIN_C_SOURCE active).
I agree. Messing with compatibility macros outside of pyconfig.h is not a good idea. Martin's hack, while likely to work in most cases, is still a hack. I believe, however we can undefine _DARWIN_C_SOURCE globally at least on 10.4 and higher. I grepped throught the headers on my 10.6 system and I notice that the majority of checks for _DARWIN_C_SOURCE are in the form of As I wrote the system will assume _DARWIN_C_SOURCE is set when when you don't set _POSIX_C_SOURCE or other feature macros. Working around that is a hack that I don't wish to support. ..
Defining _POSIX_C_SOURCE or _DARWIN_C_SOURCE causes library and kernel calls to conform to the SUSv3 standards even if doing so would alter the behavior of functions used in 10.3.
I cannot reconcile this with !defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE) logic that I see in the headers. This seems to be arranged in sys/cdefs.h. I honestly don't care how this done, the documentation clearly says that this happens and that indicates that _DARWIN_C_SOURCE selects the API Apple would like you to use. Anyway, why is this discusion on python-dev instead of in the issue tracker? BTW. IMHO resolution of this issue can wait until after 2.7.0, there is always 2.7.1 and I don't think we need to rush this (the issue has been dormant for quite a while) Ronald
"Martin v. Löwis" writes:
Still, the question would be whether any of these failures can manage to block a release.
Exactly. Personally, I would say that in a volunteer-maintained project, "Platform X is supported" means that "There is a bug that seems to affect only Platform X" is a candidate for release blocker, or other standardized action to get things fixed (call for volunteers, etc). That's a matter for agreement among the volunteers, not an objective definition. I think statements of support for certain platforms are useful to users, and that they cause very little additional friction or misunderstanding. (Users who think that "support" implies "support contract" are usually capable of finding an excuse to ignore *any* disclaimer of warrantee; simply refusing to use the word "support" won't save you from them!) If a distinction needs to be made, we can say "Python *support* for a platform does not imply that any particular issue will receive concentrated attention from the core developers in any time frame. When and how to address issues is up to the judgment of the development community. *Support contracts* are available from the businesses listed on the Wiki under 'Python Consultancies' for those who need a higher level of support."
Antoine Pitrou <solipsis@pitrou.net> wrote:
Le lundi 21 juin 2010 à 12:57 -0700, Bill Janssen a écrit :
Apparently some of these buildbots belong to you. Why don't you step up and investigate?
The fact that I'm running some buildbots doesn't mean I have to fix the problems that they reveal, I think.
You certainly don't have to. But please don't ask others to do it for you, *especially* if the failure can't be reproduced under anything else than OS X, and if no useful diagnosis is available.
I'm more concerned about doing it for *us*, rather than for *me*. Yes, an OS X machine would be required to poke at it, but I doubt I'm the only one here with an OS X machine :-). If I am, that's a problem, and we as a community should do something about that. I downloaded 2.7rc2 and built it on my Intel OS X 10.5.8 machine. It still fails the test_uuid test: % make test [...] test_uuid test test_uuid failed -- Traceback (most recent call last): File "/private/tmp/Python-2.7rc2/Lib/test/test_uuid.py", line 472, in testIssue8621 self.assertNotEqual(parent_value, child_value) AssertionError: '8395a08e40454895be537a180539b7fb' == '8395a08e40454895be537a180539b7fb' [...] However, when I run it directly: % ./python.exe -Wd -3 -E -tt ./Lib/test/regrtest.py -v test_uuid == CPython 2.7rc2 (r27rc2:82137, Jun 21 2010, 12:50:22) [GCC 4.0.1 (Apple Inc. build 5493)] == Darwin-9.8.0-i386-32bit little-endian == /private/tmp/Python-2.7rc2/build/test_python_58012 test_uuid testIssue8621 (test.test_uuid.TestUUID) ... ok test_UUID (test.test_uuid.TestUUID) ... ok test_exceptions (test.test_uuid.TestUUID) ... ok test_getnode (test.test_uuid.TestUUID) ... ok test_ifconfig_getnode (test.test_uuid.TestUUID) ... ok test_ipconfig_getnode (test.test_uuid.TestUUID) ... ok test_netbios_getnode (test.test_uuid.TestUUID) ... ok test_random_getnode (test.test_uuid.TestUUID) ... ok test_unixdll_getnode (test.test_uuid.TestUUID) ... ok test_uuid1 (test.test_uuid.TestUUID) ... ok test_uuid3 (test.test_uuid.TestUUID) ... ok test_uuid4 (test.test_uuid.TestUUID) ... ok test_uuid5 (test.test_uuid.TestUUID) ... ok test_windll_getnode (test.test_uuid.TestUUID) ... ok ---------------------------------------------------------------------- Ran 14 tests in 0.087s OK 1 test OK. % So I don't know what to think. The same thing happens with the py3kwarn test: % ./python.exe -Wd -3 -E -tt ./Lib/test/regrtest.py -v test_py3kwarn == CPython 2.7rc2 (r27rc2:82137, Jun 21 2010, 12:50:22) [GCC 4.0.1 (Apple Inc. build 5493)] == Darwin-9.8.0-i386-32bit little-endian == /private/tmp/Python-2.7rc2/build/test_python_58057 test_py3kwarn test_backquote (test.test_py3kwarn.TestPy3KWarnings) ... ok test_buffer (test.test_py3kwarn.TestPy3KWarnings) ... ok test_builtin_function_or_method_comparisons (test.test_py3kwarn.TestPy3KWarnings) ... ok test_cell_inequality_comparisons (test.test_py3kwarn.TestPy3KWarnings) ... ok test_code_inequality_comparisons (test.test_py3kwarn.TestPy3KWarnings) ... ok test_dict_inequality_comparisons (test.test_py3kwarn.TestPy3KWarnings) ... ok test_file_xreadlines (test.test_py3kwarn.TestPy3KWarnings) ... ok test_forbidden_names (test.test_py3kwarn.TestPy3KWarnings) ... ok test_frame_attributes (test.test_py3kwarn.TestPy3KWarnings) ... ok test_hash_inheritance (test.test_py3kwarn.TestPy3KWarnings) ... ok test_methods_members (test.test_py3kwarn.TestPy3KWarnings) ... ok test_object_inequality_comparisons (test.test_py3kwarn.TestPy3KWarnings) ... ok test_operator (test.test_py3kwarn.TestPy3KWarnings) ... ok test_paren_arg_names (test.test_py3kwarn.TestPy3KWarnings) ... ok test_slice_methods (test.test_py3kwarn.TestPy3KWarnings) ... ok test_softspace (test.test_py3kwarn.TestPy3KWarnings) ... ok test_sort_cmp_arg (test.test_py3kwarn.TestPy3KWarnings) ... ok test_sys_exc_clear (test.test_py3kwarn.TestPy3KWarnings) ... ok test_tuple_parameter_unpacking (test.test_py3kwarn.TestPy3KWarnings) ... ok test_type_inequality_comparisons (test.test_py3kwarn.TestPy3KWarnings) ... ok test_mutablestring_removal (test.test_py3kwarn.TestStdlibRemovals) ... ok test_optional_module_removals (test.test_py3kwarn.TestStdlibRemovals) ... ok test_os_path_walk (test.test_py3kwarn.TestStdlibRemovals) ... ok test_platform_independent_removals (test.test_py3kwarn.TestStdlibRemovals) ... ok test_platform_specific_removals (test.test_py3kwarn.TestStdlibRemovals) ... /private/tmp/Python-2.7rc2/Lib/plat-mac/findertools.py:303: SyntaxWarning: tuple parameter unpacking has been removed in 3.x def _setlocation(object_alias, (x, y)): /private/tmp/Python-2.7rc2/Lib/plat-mac/findertools.py:445: SyntaxWarning: tuple parameter unpacking has been removed in 3.x def _setwindowsize(folder_alias, (w, h)): /private/tmp/Python-2.7rc2/Lib/plat-mac/findertools.py:496: SyntaxWarning: tuple parameter unpacking has been removed in 3.x def _setwindowposition(folder_alias, (x, y)): ok test_reduce_move (test.test_py3kwarn.TestStdlibRemovals) ... ok ---------------------------------------------------------------------- Ran 26 tests in 0.343s OK 1 test OK. % The only failing test remaining, when run as a singleton, is test_urllib_localnet: % ./python.exe -Wd -3 -E -tt ./Lib/test/regrtest.py -v test_urllib2_localnet == CPython 2.7rc2 (r27rc2:82137, Jun 21 2010, 12:50:22) [GCC 4.0.1 (Apple Inc. build 5493)] == Darwin-9.8.0-i386-32bit little-endian == /private/tmp/Python-2.7rc2/build/test_python_58063 test_urllib2_localnet test_proxy_qop_auth_int_works_or_throws_urlerror (test.test_urllib2_localnet.ProxyAuthTests) ... ok test_proxy_qop_auth_works (test.test_urllib2_localnet.ProxyAuthTests) ... ok test_proxy_with_bad_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests) ... FAIL test_proxy_with_no_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests) ... FAIL test_200 (test.test_urllib2_localnet.TestUrlopen) ... ok test_200_with_parameters (test.test_urllib2_localnet.TestUrlopen) ... ok test_404 (test.test_urllib2_localnet.TestUrlopen) ... ok test_bad_address (test.test_urllib2_localnet.TestUrlopen) ... ok test_basic (test.test_urllib2_localnet.TestUrlopen) ... ok test_geturl (test.test_urllib2_localnet.TestUrlopen) ... ok test_info (test.test_urllib2_localnet.TestUrlopen) ... ok test_redirection (test.test_urllib2_localnet.TestUrlopen) ... ok test_sending_headers (test.test_urllib2_localnet.TestUrlopen) ... ok ====================================================================== FAIL: test_proxy_with_bad_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/private/tmp/Python-2.7rc2/Lib/test/test_urllib2_localnet.py", line 264, in test_proxy_with_bad_password_raises_httperror self.URL) AssertionError: HTTPError not raised ====================================================================== FAIL: test_proxy_with_no_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/private/tmp/Python-2.7rc2/Lib/test/test_urllib2_localnet.py", line 270, in test_proxy_with_no_password_raises_httperror self.URL) AssertionError: HTTPError not raised ---------------------------------------------------------------------- Ran 13 tests in 9.050s FAILED (failures=2) test test_urllib2_localnet failed -- multiple errors occurred 1 test failed: test_urllib2_localnet % Bill
Bill Janssen <janssen@parc.com> wrote:
% make test [...] test_uuid test test_uuid failed -- Traceback (most recent call last): File "/private/tmp/Python-2.7rc2/Lib/test/test_uuid.py", line 472, in testIssue8621 self.assertNotEqual(parent_value, child_value) AssertionError: '8395a08e40454895be537a180539b7fb' == '8395a08e40454895be537a180539b7fb'
[...]
I reopened http://bugs.python.org/issue8621 . Could you comment there and help resolve the test failure? Stefan Krah
On 21/06/2010 20:30, Benjamin Peterson wrote:
2010/6/21 Bill Janssen<janssen@parc.com>:
They are at the end of the buildbot list, so off-screen if you are using a normal browser. You have to scroll to see them.
But not on the "stable" view and that's the only one I look at.
What are the requirements for moving the OS X buildbots into the stable view? Are the builders themselves stable enough? (If the requirement is that the buildbots be green then it is something of a catch-22.) All the best, Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
Am 21.06.2010 21:45, schrieb Michael Foord:
On 21/06/2010 20:30, Benjamin Peterson wrote:
2010/6/21 Bill Janssen<janssen@parc.com>:
They are at the end of the buildbot list, so off-screen if you are using a normal browser. You have to scroll to see them. But not on the "stable" view and that's the only one I look at.
What are the requirements for moving the OS X buildbots into the stable view? Are the builders themselves stable enough? (If the requirement is that the buildbots be green then it is something of a catch-22.)
It is indeed the latter (at least, how I understand it). The builder should "usually" give green, which means it should have done so over some extended period of time. If it then gets broken it means that somebody actually broke the code, rather than the system showing one of its glitches. So asking for addition to the stable list *while* the slave is red is a bad idea. FWIW, nobody has requested changing any of the build slaves to "stable" for the last two years or so. Regards, Martin
Benjamin Peterson <benjamin@python.org> wrote:
2010/6/21 Bill Janssen <janssen@parc.com>:
They are at the end of the buildbot list, so off-screen if you are using a normal browser. You have to scroll to see them.
But not on the "stable" view and that's the only one I look at.
Right, and properly so. Bill
On Mon, 21 Jun 2010 10:56:59 PDT Bill Janssen <janssen@parc.com> wrote:
Considering that we've just released 2.7rc2, there are an awful lot of red buildbots for 2.7. In fact, I don't remember having seen a green buildbot for OS X and 2.7. Shouldn't these be fixed?
On OS X Leopard, I'm seeing failures in test_py3kwarn, test_urllib2_localnet, test_uuid.
On OS X Tiger, I'm seeing failures in test_pep277, test_py3kwarn, test_ttk_guionly, and test_urllib2_localnet.
I'm afraid they can only be fixed by whoever is competent on OS X issues. If you want to tackle them, you're more than welcome. There also seem to be a couple of failures left with test_gdb... Regards Antoine.
There also seem to be a couple of failures left with test_gdb...
Do you mean the compiler and debugger specific issues reported in http://bugs.python.org/issue8482? Fixing that properly is messy, and according to Victor's last message, even the correct conditions for skipping the test aren't completely clear. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 21 June 2010 18:56, Bill Janssen <janssen@parc.com> wrote:
Considering that we've just released 2.7rc2, there are an awful lot of red buildbots for 2.7. In fact, I don't remember having seen a green buildbot for OS X and 2.7. Shouldn't these be fixed?
Ack! My buildbot has looked fine, but on closer inspection, it was the same build that's been running (more accurately, stuck in a test) for 5 days :-( The main buildslave page looked fine - except for the dates, which I didn't spot. Thanks for the alert. I've killed the stuck test and should see some runs going through now. Shame, really, I was getting used to seeing a nice page of all green results... Paul.
Paul Moore <p.f.moore@gmail.com> writes:
Thanks for the alert. I've killed the stuck test and should see some runs going through now. Shame, really, I was getting used to seeing a nice page of all green results...
In my experience, my OSX and Windows buildbots need some manual TLC on an ongoing basis. I kill off stranded python processes several times a week on both platforms. OSX actually seems as bad as Windows in this regard, which is strange given its *nix heritage, but perhaps its how some of the test processes are created. Most of the time the stranded processes aren't hurting anything but local resource, but sometimes they can lock directories, or hang a build/test for a particular builder. My windows buildbots also have a tendency to fill up temp, or even if there's room, get sluggish due to all the cruft left in that directory, so I periodically clean that out manually as well. -- David
On Jun 21, 2010, at 1:56 PM, Bill Janssen wrote:
Considering that we've just released 2.7rc2, there are an awful lot of red buildbots for 2.7. In fact, I don't remember having seen a green buildbot for OS X and 2.7. Shouldn't these be fixed?
On OS X Leopard, I'm seeing failures in test_py3kwarn, test_urllib2_localnet, test_uuid.
On OS X Tiger, I'm seeing failures in test_pep277, test_py3kwarn, test_ttk_guionly, and test_urllib2_localnet.
We don't have a buildbot running Snow Leopard, apparently.
On my OS X 10.6.4 box, only test_py3kwarn and test_urllib2_localnet fail. -Barry
Bill Janssen <janssen@parc.com> wrote:
Considering that we've just released 2.7rc2, there are an awful lot of red buildbots for 2.7. In fact, I don't remember having seen a green buildbot for OS X and 2.7. Shouldn't these be fixed?
Thanks to some action by Ronald, my two PPC OS X buildbots are now showing green for the trunk. Bill
participants (14)
-
"Martin v. Löwis" -
Alexander Belopolsky -
Antoine Pitrou -
Barry Warsaw -
Benjamin Peterson -
Bill Janssen -
David Bolen -
Michael Foord -
Nick Coghlan -
Paul Moore -
Ronald Oussoren -
ronaldoussoren
-
Stefan Krah -
Stephen J. Turnbull