WinBuilders recently had a number of changes checked in to support later pywin32 versions and numerous fixes. At around the same time WinBuilders was copied into the Zope 2.7 and 2.8 trees - but without these improvements. This is the underlying reason behind the 2.8 binaries for Windows not being correct. I've created a patch that reinstates the lost changes in both the Zope 2.7 and 2.8 trees and attached it to http://www.zope.org/Collectors/Zope/1782 As mentioned in that collector issue: * inst/WinBuilders has been added to Zope 2.8 without the svn:eol-style=native setting. This property must be set on that entire tree before attempting to apply the patch. Apart from that, the patch applies to both 2.7 and 2.8 * The old WinBuilders (at Packages/WinBuilders) should be removed from CVS to avoid future confusion. The Zope 2.8 binary appears to install and start fine, but all I tested was that the ZMI would open. Another change I snuck in was to add 'SolidCompression=yes' to the Inno file - this reduces the final .exe by about 40% Unfortunately I still haven't heard anything re my contributor agreement, so am unable to make these changes myself. I will ask Sidnei very nicely tomorrow, but if anyone else is able to assist, please just go for it :) Mark
--On Montag, 16. Mai 2005 16:46 Uhr +1000 Mark Hammond <mhammond@skippinet.com.au> wrote:
The Zope 2.8 binary appears to install and start fine, but all I tested was that the ZMI would open. Another change I snuck in was to add 'SolidCompression=yes' to the Inno file - this reduces the final .exe by about 40%
Unfortunately I still haven't heard anything re my contributor agreement, so am unable to make these changes myself. I will ask Sidnei very nicely tomorrow, but if anyone else is able to assist, please just go for it :)
I think Jim is in charge for the contributor agreements. Maybe you can buzz him directly. I would like to cut the 2.8 beta 2 release this weekend. So I hope that the windows related issues are fixed until Sunday. I hope anyone can fix the ZConfig issue with the default IP address when Zope starts up. For me this is not a release blocker. If the Zope windows users don't care about it then I don't care as well. If someone wants this to be fixed someone should fix it...otherwise seems to be a bug the windows users can live with *wink*. -aj
[Mark Hammond]
WinBuilders recently had a number of changes checked in to support later pywin32 versions and numerous fixes. At around the same time WinBuilders was copied into the Zope 2.7 and 2.8 trees - but without these improvements. This is the underlying reason behind the 2.8 binaries for Windows not being correct.
Not to mention the released Zope 2.7.6.
I've created a patch that reinstates the lost changes in both the Zope 2.7 and 2.8 trees and attached it to http://www.zope.org/Collectors/Zope/1782
Thanks!
As mentioned in that collector issue:
* inst/WinBuilders has been added to Zope 2.8 without the svn:eol-style=native setting. This property must be set on that entire tree before attempting to apply the patch.
I did that part this morning.
Apart from that, the patch applies to both 2.7 and 2.8
* The old WinBuilders (at Packages/WinBuilders) should be removed from CVS to avoid future confusion.
I did some stuff in that direction on HEAD, but that's all. I'm sure the only people who ever tried to use WinBuilders are aware that 2.7 and 2.8 have grown their own versions.
The Zope 2.8 binary appears to install and start fine, but all I tested was that the ZMI would open.
That's a good start, but see below.
Another change I snuck in was to add 'SolidCompression=yes' to the Inno file - this reduces the final .exe by about 40%
Cool!
Unfortunately I still haven't heard anything re my contributor greement, so am unable to make these changes myself.
Jim (Fulton) found & processed your contrib agreement since you wrote this, so you should be all set now. [Andreas Jung]
I would like to cut the 2.8 beta 2 release this weekend. So I hope that the windows related issues are fixed until Sunday. I hope anyone can fix the ZConfig issue with the default IP address when Zope starts up.
That wasn't the problem. The problem was that Zope on Windows couldn't be told to listen on a hostname _other than_ localhost. Even if you set ip-address in zope.conf, it seemed to be ignored on Windows, and Zope still wound up listening (only) on localhost. Note that this new-ish test still fails on Windows on Zope trunk: FAIL: test_http_factory_defaulthost (ZServer.tests.test_config.ZServerConfigurationTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Code\Zope\lib\python\ZServer\tests\test_config.py", line 121, in test_http_factory_defaulthost 'Zope Collector issue #1507/1728 (ignoring ' File "C:\python23\lib\unittest.py", line 302, in failUnlessEqual raise self.failureException, \ AssertionError: Zope Collector issue #1507/1728 (ignoring defaulthost): '127.0.0.1' != '0.0.0.0' IIUC, repairing this requires changing ZConfig.
For me this is not a release blocker.
If that problem remains, it would seem it make Zope 2.8 pretty much useless on Window. It would, however, pass Mark's test above <wink>.
--On Montag, 16. Mai 2005 13:58 Uhr -0400 Tim Peters <tim.peters@gmail.com> wrote:
IIUC, repairing this requires changing ZConfig.
For me this is not a release blocker.
If that problem remains, it would seem it make Zope 2.8 pretty much useless on Window. It would, however, pass Mark's test above <wink>.
Maybe nobody needs Zope 2.8 on Windows...otherwise someone would fix it *wink* :-) Andreas
[Tim]
Unfortunately I still haven't heard anything re my contributor greement, so am unable to make these changes myself.
Jim (Fulton) found & processed your contrib agreement since you wrote this, so you should be all set now.
Excellent - thanks Jim! I have checked those WinBuilder patches into Zope 2.7 CVS and 2.8 SVN. I hope I did it correctly :) Cheers, Mark
[Tim]
[Andreas Jung]
I would like to cut the 2.8 beta 2 release this weekend. So I hope that the windows related issues are fixed until Sunday. I hope anyone can fix the ZConfig issue with the default IP address when Zope starts up.
That wasn't the problem. The problem was that Zope on Windows couldn't be told to listen on a hostname _other than_ localhost. Even if you set ip-address in zope.conf, it seemed to be ignored on Windows, and Zope still wound up listening (only) on localhost.
Note that this new-ish test still fails on Windows on Zope trunk:
I think we have 2 issues here: * There is a bug in ZConfig such that if a default is provided for *both* hostname and IP, things don't behave as expected. This bug probably exists on all platforms, but is only seen on Windows since it provides defaults for the 2 values. * It is still unclear why Windows has a different default in the first place. Thus there seem to be 2 ways to move forward: 1) Remove the different behaviour for Windows. 2) Fix the underlying ZConfig error, and document somewhere the reasons for the change. Without any understanding of why Windows requires different behaviour (and with no-one stepping up to the plate to look at ZConfig), the best way forward may be (1). Assuming all our tests pass we can then wait for the bug-reports to roll in (or not!) regarding this change in behaviour. We can then make an effort to understand and document the issue, and resolve it in a 2.8.x release. Mark
Hi Mark! Mark Hammond wrote:
I think we have 2 issues here:
* There is a bug in ZConfig such that if a default is provided for *both* hostname and IP, things don't behave as expected. This bug probably exists on all platforms, but is only seen on Windows since it provides defaults for the 2 values.
Can't follow you. Please have a look at my summary in Entry #22 of http://www.zope.org/Collectors/Zope/1507
* It is still unclear why Windows has a different default in the first place.
Tim explained that in Entry #5 of http://www.zope.org/Collectors/Zope/1728
Thus there seem to be 2 ways to move forward:
1) Remove the different behaviour for Windows.
This is already done (in Zope, not in ZConfig). See http://svn.zope.org/?view=rev&rev=30303
2) Fix the underlying ZConfig error, and document somewhere the reasons for the change.
Fred volunteered to resolve the ZConfig issue, see Entry #23 of http://www.zope.org/Collectors/Zope/1507 Cheers, Yuppie
I rewrote ZRS's Windows service code to use the new named events set by current versions of Zope's nt_svcutils/service.py. Overall, this works really slick, but with a glitch: the ZRS log files suggest that the "signal" events never get set when Windows is shutting down, they only fire when the user explicitly stops/restarts a ZRS service. That isn't good for ZRS -- it's managing a database, and really wants a chance to flush in-memory data structures to disk, no matter how the service gets stopped. I don't think it's "a feature" to skip clean shutdown for a Zope service either. So, best guesses (please scream where I'm wrong): - This is because service.py doesn't define a SvcShutdown method, just a SvcStop method, - It's a good idea to add a SvcShutdown method to service.py. - It would suffice to add SvcShutdown = SvcStop to service.py. If nobody disagrees (or even if everyone disagrees except Mark <wink>), I'll add that to the various Zope branches.
[Tim]
So, best guesses (please scream where I'm wrong):
- This is because service.py doesn't define a SvcShutdown method, just a SvcStop method,
- It's a good idea to add a SvcShutdown method to service.py.
- It would suffice to add
SvcShutdown = SvcStop
to service.py.
If nobody disagrees (or even if everyone disagrees except Mark <wink>), I'll add that to the various Zope branches.
Thanks Tim - I'd never noticed that omission. You are completely correct. I'll test this next time I need to reboot (which contrary to popular opinion isn't that often <wink>). Mark.
[Tim Peters] [...]
So, best guesses (please scream where I'm wrong):
- This is because service.py doesn't define a SvcShutdown method, just a SvcStop method,
- It's a good idea to add a SvcShutdown method to service.py.
- It would suffice to add
SvcShutdown = SvcStop
to service.py. |>> If nobody disagrees (or even if everyone disagrees except Mark <wink>), I'll add that to the various Zope branches.
[Mark Hammond]
Thanks Tim - I'd never noticed that omission. You are completely correct. I'll test this next time I need to reboot (which contrary to popular opinion isn't that often <wink>).
Cool! I can testify that adding SvcShutdown to ZRS's service subclass (just invoking the base class SvcStop) did cure ZRS's Windows shutdown oddities and didn't appear to create any new problems, so I'm much more confident now. I'll fiddle the various Zopes' base service classes instead tomorrow. Thanks for the brain cells!
participants (4)
-
Andreas Jung -
Mark Hammond -
Tim Peters -
yuppie