[Python-Dev] Compiling Python 3.2 on Cygwin fails (original) (raw)

Brian Curtin brian.curtin at gmail.com
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>

More information about the Python-Dev mailing list