[Python-Dev] Compiling Python 3.2 on Cygwin fails

Wed Jul 6 02:38:29 CEST 2011

On Tue, Jul 5, 2011 at 15:10, Dan Stromberg <drsalists at gmail.com> wrote:
>> On Tue, Jul 5, 2011 at 1:00 PM, Brian Curtin <brian.curtin at gmail.com>wrote:
>>> On Tue, Jul 5, 2011 at 14:41, Dan Stromberg <drsalists at gmail.com> wrote:
>>>>>>>> On Tue, Jul 5, 2011 at 12:18 PM, Brian Curtin <brian.curtin at gmail.com>wrote:
>>>>>>> On Tue, Jul 5, 2011 at 14:12, Dan Stromberg <drsalists at gmail.com>wrote:
>>>>>>>>>>>>>> On Tue, Jul 5, 2011 at 7:25 AM, David Robinow <drobinow at gmail.com>wrote:
>>>>>>>>>>>>>>>>> Cygwin is not really a supported platform.
>>>>>>>>>> ...
>>>>>>>>>>> [Ultimately somebody with an
>>>>>> interest in cygwin will need to get active in python development. I've
>>>>>> been meaning to do this but life gets in the way.]
>>>>>>>>>>>>>>>> I was bitten by the lack of Cygwin support in 3.2 as well.
>>>>>>>>>> IMO, python-dev needs continuous integration on a build farm that
>>>>> includes representative platforms. Most of the machines in the farm could
>>>>> be virtualboxes.
>>>>>>>>>> I don't think the problem is so much that the right people haven't
>>>>> gotten involved, as that the currently-involved people don't know when
>>>>> they're breaking something for someone else due to the lack of continuous
>>>>> integration.
>>>>>>>>>>>>> We've had that for some time now: http://www.python.org/dev/buildbot/
>>>>>>>>>> Good to know. Apologies for my incorrect assumption. Where do the
>>> e-mail notifications of build and/or test failures go?
>>>>>>> There might be an RSS feed or something, but I don't think there's any
>> email notification. #python-dev on IRC receives live failure info. Other
>> than that, you'd just have to look at one of the views of the fleet to see
>> which build slaves are failing.
>>>> Am I correct in assuming that "stable" buildbots are required to be
> reasonably functional before a release is tagged?
>
Yep - all green is the goal.
>>>> Shouldn't Cygwin be represented here? I don't see it in the list of
>>> builds.
>>>>>>> Probably, but it isn't represented because no one contributed a build
>> slave for it. I know some of the other Windows build slave operators use
>> Cygwin to some degree, but I'm not sure if anyone has looked into actually
>> setting up a build slave for it.
>>>> I see.
>>>> Some shops have a policy that nothing gets merged into trunk unless it's
>>> passing critical automated tests... Would that work here?
>>>>>>> We don't make much use of branching, but that would work if we did. If no
>> one is actively contributing work on the Cygwin build then I don't see us
>> holding up work in order to figure out any Cygwin-specific issues.
>>>> I might suggest that doing so (using branching, keeping trunk stable) might
> be of benefit, especially with a DVCS.
>>>>>> There are several issues on the bug tracker about cygwin build issues, but
>>>> to my knowledge, none of them have included successful patches.
>>>>>>>>>> I think you'll find that most people using Cygwin would rather be working
>>> on some other OS, but are forced to use Windows for policy reasons. It's
>>> remains a rather significant need in many cases.
>>>>>>> I don't disagree with that, but if there's no one contributing Cygwin
>> patches then it will probably just die off and we'll have situations like
>> the current one where it doesn't build. A great majority of the contributing
>> developers are on UNIX-based systems with no access to Windows. A small
>> handful, myself included, are Windows users, but I don't think any of us use
>> Cygwin (I don't).
>>>> I see.
>> Is there a python.org resource for setting up mailing lists - say, for a
> python-cygwin mailing list?
>
You might want to suggest something like cygwin-sig as a mailing list. Check
out http://www.python.org/community/sigs/guidelines/ for more info.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110705/51a9fe8f/attachment.html>