[Python-Dev] Compiling Python 3.2 on Cygwin fails

[Brian Curtin]

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>