Re: [Python-Dev] Compiling Python 3.2 on Cygwin fails
On Tue, Jul 5, 2011 at 7:25 AM, David Robinow <drobinow@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.
On Tue, Jul 5, 2011 at 14:12, Dan Stromberg <drsalists@gmail.com> wrote:
On Tue, Jul 5, 2011 at 7:25 AM, David Robinow <drobinow@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/ There are several issues on the bug tracker about cygwin build issues, but to my knowledge, none of them have included successful patches.
On Tue, Jul 5, 2011 at 12:18 PM, Brian Curtin <brian.curtin@gmail.com>wrote:
On Tue, Jul 5, 2011 at 14:12, Dan Stromberg <drsalists@gmail.com> wrote:
On Tue, Jul 5, 2011 at 7:25 AM, David Robinow <drobinow@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? Shouldn't Cygwin be represented here? I don't see it in the list of builds. Some shops have a policy that nothing gets merged into trunk unless it's passing critical automated tests... Would that work here? 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. How does the buildbot initiate builds? ssh? Happily Cygwin mostly allows sshd (as long as you don't need a CIFS share or something). Native Windows builds do appear to be represented. Is there any reason not to set up a buildbot for Cygwin on the same (virtual?) hardware? I'm inclined to believe that whoever rearranged the shared object stuff in CPython 3.x's build system would've been more careful if they'd had feedback about what it was doing to Cygwin.
On Tue, Jul 5, 2011 at 14:41, Dan Stromberg <drsalists@gmail.com> wrote:
On Tue, Jul 5, 2011 at 12:18 PM, Brian Curtin <brian.curtin@gmail.com>wrote:
On Tue, Jul 5, 2011 at 14:12, Dan Stromberg <drsalists@gmail.com> wrote:
On Tue, Jul 5, 2011 at 7:25 AM, David Robinow <drobinow@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.
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. 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. 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). Native Windows builds do appear to be represented. Is there any reason not
to set up a buildbot for Cygwin on the same (virtual?) hardware?
Besides the time and effort needed to set it up and occasionally look over it, no. We'd have to have a successfully compiling Cygwin build before we think about adding a build slave for it. I wouldn't be opposed to hosting this myself, but I need to steal some time and get my Windows 2008 build slave back to some form of a functional system - it has been up and down for a few months now. If someone else is interested, go ahead.
On Tue, Jul 5, 2011 at 1:00 PM, Brian Curtin <brian.curtin@gmail.com> wrote:
On Tue, Jul 5, 2011 at 14:41, Dan Stromberg <drsalists@gmail.com> wrote:
On Tue, Jul 5, 2011 at 12:18 PM, Brian Curtin <brian.curtin@gmail.com>wrote:
On Tue, Jul 5, 2011 at 14:12, Dan Stromberg <drsalists@gmail.com> wrote:
On Tue, Jul 5, 2011 at 7:25 AM, David Robinow <drobinow@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?
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?
Native Windows builds do appear to be represented. Is there any reason not
to set up a buildbot for Cygwin on the same (virtual?) hardware?
Besides the time and effort needed to set it up and occasionally look over it, no. We'd have to have a successfully compiling Cygwin build before we think about adding a build slave for it.
That makes sense.
I wouldn't be opposed to hosting this myself, but I need to steal some time and get my Windows 2008 build slave back to some form of a functional system - it has been up and down for a few months now. If someone else is interested, go ahead.
I might contribute some elbow grease if someone could get me VNC access to a suitable Windows server. BTW, is there someone available who is familiar with the meanings of the various shared object-related make symbols? I glanced at them and didn't find their naming astonishingly clear - seems like something to document, or... maybe it already is, and I just haven't seen where it is yet.
On Tue, Jul 5, 2011 at 15:10, Dan Stromberg <drsalists@gmail.com> wrote:
On Tue, Jul 5, 2011 at 1:00 PM, Brian Curtin <brian.curtin@gmail.com>wrote:
On Tue, Jul 5, 2011 at 14:41, Dan Stromberg <drsalists@gmail.com> wrote:
On Tue, Jul 5, 2011 at 12:18 PM, Brian Curtin <brian.curtin@gmail.com>wrote:
On Tue, Jul 5, 2011 at 14:12, Dan Stromberg <drsalists@gmail.com>wrote:
On Tue, Jul 5, 2011 at 7:25 AM, David Robinow <drobinow@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.
On Wed, Jul 6, 2011 at 10:38 AM, Brian Curtin <brian.curtin@gmail.com> wrote:
On Tue, Jul 5, 2011 at 15:10, Dan Stromberg <drsalists@gmail.com> wrote:
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.
Indeed, that's the main difference between the stable and unstable buildbots. stable = this should work. If it doesn't, somebody broke something and the relevant branch should be fixed unstable = someone cared enough to set up this buildbot, but due to problems with either the platform in general or the specific machine it spends a lot of its time red for reasons that aren't the fault of recent changes to Python A Cygwin buildbot would start in the latter category then potentially migrate to stable if it proved itself with green results over a period of time. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (3)
-
Brian Curtin -
Dan Stromberg -
Nick Coghlan