[David H]
Thanks for responding. I tried the suggestion:
C:\Zope-2.8.0a2 python.exe setup.py build_ext --inplace
and the thing runs for a while (good sign, as visual c 6.0 is compiling
things) then I get this:
building
[Guillaume Tamboise]
Let's say that I have a happily running server, that I get quite a lot of
flipping cache files with a cache-size at 6000 in my Zope instances, and
that I want to improve performances.
What should I do?
I suspect you're confusing the ZODB cache (an in-memory cache measured
[Chris McDonough]
This is actually normal. See the end of
http://www.plope.com/Books/2_7Edition/Sessions.stx (Conflict Errors)
for a short explanation.
Conflict errors are certainly normal, but IIUC the OP is seeing site
errors, not just log msgs. The text referenced also says:
The
...
[Tim Peters]
Conflict errors are certainly normal, but IIUC the OP is seeing site
errors, not just log msgs ...
[Chris McDonough]
This is true. I misunderstood the OP inasmuch as I thought he was
seeing the error message in his event log, which would be normal It is
certainly
[Tres Seaver]
Assuming a standard build environment (make, gcc, etc.),
'zlib' is the only one which typically bites me on a new
machine -- Python will build in its absence, but ZODB won't.
What's that about? The only part of ZODB that uses zlib/gzip is the
repozo.py backup script.
[Tim]
What's that about? The only part of ZODB that uses
zlib/gzip is the repozo.py backup script.
[Tres]
Hmm, I don't know; I was basing it on a memory of building
out a ZEO storage server on a bare bones Unix box, and
having something during the build / startup phase barf,
complaining
[Pascal Peregrina]
In a Zope / Zeo configuration (2.7.6), is there a way, on the Zope
instance, to know when the database (Zeo) was last packed ?
[Chris Withers]
Publicly, maybe not, but there'll definitely be away to find it out
since the pack machinery checks this.
Sorry, pack times aren't
[gabor]
i am trying to backup a zodb filestorage of a running zope.
i'm on linux.
i've read that you simply make a copy of the Data.fs file..
but what about the modifications/transactions that are happening when i
make the copy.
will not the database be in a corrupt state then?
It can
[gabor]
i understand that you need to use ZEO when running ZOPE on a multi-cpu
machine (or when you want to cluster ZOPE).
but from mails on this forum it seems that people are also using ZEO
when they're running ZOPE on a single-cpu machine.
why?
More here:
[Felix Ulrich-Oltean]
...
I think I've found the culprits - there are 4 records which give errors like
this:
portal.portal_catalog.uncatalog_object('/sites/cw/data/urbanr')
Traceback (most recent call last):
File stdin, line 1, in ?
File
[Felix Ulrich-Oltean]
I'm using the repozo.py script to back up some large FileStorages, as
outlined in:
http://www.zope.org/Wikis/ZODB/FileStorageBackup
I need to clear out old backups regularly, as there are several
storages which are packed every night, and so there are lots of ~2G
[Eddie Butcher]
What would be most useful is the ability to specify the number of backup
files *kept*.
Please add comments to the Collector issue instead? On a mailing
list. they're forgotten forever an hour after they're posted 0.1
wink:
http://www.zope.org/Collectors/Zope/1501
[Dennis Allison]
The download list at zope.org does not have any releases between 2.7.3
and 2.8. We've been using 2.7.6 and would like to be able to download
clean copies...
The download list at
http://www.zope.org/Products/Zope/
has an entry for 2.7.6. If you ended up at
[Etienne Labuschagne]
...
I really need a temporary connection that I can discard. This
connection can have a much smaller cache than the normal connections
as it makes very little difference in the speed of data loading.
Second prize is a connection that will only be used by a specific
[Matt Hamilton]
...
We have been running Zope on OpenBSD/AMD64 3.6 for about a year now
and it works pretty well. I have however recently discovered a python bug
that I am trying to track down. I am unsure of the exact problem, but it
affects the re and string libs:
zeo1# uname -a
[Tim Peters]
...
I don't know, and I haven't seen this reported by anyone else before.
Let's try this: cd to your Zope's (not Zope-Instance's) bin
directory, and start Python from there. Your DOS box should look like
this then:
C:\Zope-2.8.0-final\binpython
Python 2.3.5 (#62, Feb 8 2005
...
[Martin Raspe]
I see the same error message that ZOPE gives.
[Tim Peters]
FYI, pasting the exact DOS box input and output (as I did above) saves
the reader from needing to guess at 100 details.
Any solution?
Sorry, not unless someone can give useful information. If you're
familiar
[Sune B. Woeller]
...
I can see (with the excellent (and free) 'Process
Explorer' from sysinternals) that the python
processes always opens port 1, and connects by
that port to themselves on another port (for
instance 2550).
[Dieter Maurer]
You can find the relevant code in
[Tim Peters]
Yup. ZODB has what looks like a copy/paste of this code, in
ZEO/zrpc/trigger.py. I didn't realize where it came from originally
until you pointed out the Medusa code here.
Anyway, it so happens I rewrote ZEO's copy a few weeks ago, in ZODB
3.4. The Windows part is much
truly was ;-)
I have tested the new code from Tim Peters, it apparently works, ports are
given
out by windows.
But could the same problem with bind occur here, since a is closed (and
garbage
collected) ? (far less chance for that since we do not specify port numbers, I
know).
I tried
[Sune B. Woeller]
I will try to recreate the problem on other
flavours of windows asap. I will get back to you
later.
Cool! If you can, posting a self-contained program that demonstrates
the problem is the best way to make progress.
I guess my reporting was a bit too quick, sorry:
Not at
[Tim Peters]
...
Ran that loop in two processes. No hangs, or any
other oddities, for some minutes. It did _eventually_ hang-- and both
processes at the same time --with netstat showing more than 4000
sockets hanging around in TIME_WAIT state then. I assume I bashed
into some
It's starting to look a lot like the Windows bind() implementation is
unreliable, sometimes (but rarely -- hard to provoke) allowing two
sockets to bind to the same (address, port) pair simultaneously,
instead of raising 'Address already in use' for one of them. Disaster
ensues.
WRT the last
[Sune B. Woeller]
...
This is what I'm experiencing as well.
I can narrow it down a bit: I *always* experience one out of two
erroneous behaviours, as described below.
I see only one of the behaviors below (the second -- no problems), and
don't agree it's in error.
I tried to make an even
[Sune B. Woeller]
...
But then I stumbled upon this flag in the WinSock documentation:
SO_EXCLUSIVEADDRUSE
See the description here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/using_so_exclusiveaddruse.asp
Right, I vaguely wink knew about that. Note that
[Tim]
...
At this point, I wouldn't consider using it [SO_EXCLUSIVEADDRUSE]
unless someone first took the tedious time it needs to demonstrate that
when it is used, the thing that _I_ think is a bug here goes away in its
presence: the seeming ability of Windows to sometimes permit more
than
The attached hasn't failed on my box (Win XP Pro SP2, Python 2.3.5)
for about two hours, running it in 3 processes. Was using 2 processes
before; discovered it was much easier to provoke problems using 3; but
the # of ephemeral ports in use increases too, typically hovering
between 7-8 thousand
...
[Tim Peters[
How often do you see this? I haven't seen it yet, but I can't make
hours today to do this [by] hand.
[Sune B. Woeller]
The problem with a failing connect, and as consequence a hanging accept:
I have tested with your socktest111(), and experience the same thing
[Sune B. Woeller, on socktest29]
I have been running 8 simultaneous processes with socktest29() for
12 hours, on my xp box. No problems except for an occasional Address
already in use.
Which the code expects, and works around. Thank you, Sune! I ran the
same code, but with 3 processes, for
[Sune B. Woeller]
...
Sounds great with the ZODB changes. What releases will this cover ?
If more releases are due in the 2.7.x line, it would be great if they could be
included.
ZODB and Medusa changes have already been checked in for the 2.7.x
line. For the rest, please see
[Maciej Wisniowski]
...
One more question - am I correct that _p_resolveConflict
is not used anymore in Zope 2.8.x?
Not correct. _p_resolveConflict is used in Zope 2.8.x (and in Zope 3)
exactly the same way it was used in 2.7.x. If it's not working, there
may be a new bug in 2.8.x, but
[Maciej Wisniowski, wrestling with _p_resolveConflict]
Because of errors like:
ConflictError: database conflict error (oid 0x0299de, class
Products.DCOracle2.DA.Procedure, serial this txn started with
0x035f0726c7bfca88 2005-08-01 08:38:46.816215, serial currently
committed
[Tim Peters]
Offhand it looks OK to me, but I don't have any of the code you're
using.
[Maciej Wisniowski]
I think that it's not my code problem but rather something with
DCOracle2 and to reproduce this error it is enough to call
any 'DCOracle2 StoredProcedure' object simultaneously
[Andy Altepeter]
I ran fsrecover.py on a copy of my Data.fs. It found no errors, but then when
it attempted to pack the file, it raised an unpickleable error, with this
traceback:
...
File /export1/Zope-2.7.5-final/lib/python/ZODB/referencesf.py, line 38, in
referencesf
raise
[Andreas Krasa]
We are encountering some really strange problems with Zope 2.7.7 on our
RedHat EL 4 Linux machines.
During the Zope 2.7.7 compilation works - however most of the time make
test returns a random number of errors (somewhere between 20 and 30)
ALL related to ZEO.
The funny
[Andreas Krasa]
So you showed a number of test errors here, all on line 121 of
ConnectionTests.py. They all seem indentical to the first one:
ERROR: checkMultipleAddresses
(ZEO.tests.testConnection.MappingStorageConnectionTests)
[David]
...
The problem occurs when trying to paste [I/O Error: not enough space
on the device] the library (copy command seems to work) or import
(export seems to work).
[Dieter Maurer]
Hmmm:
This verbal report does not at all fits to the traceback
below...
An IOError: not enough
[Andreas Krasa]
...
As I understood Dieter's mail, this strange behavior is caused by the
way RedHat Enterprise Linux 4 system libraries handle SIG_IGN/SIGCHLD.
I don't know. Dieter asked whether you ran the tests via zopectl
test, but I didn't see an answer to that. If you run the Zope
[Willi Langenberger]
Ok, here some data points...
bender:~/Zope-2.7.7-final$ cat /proc/version
Linux version 2.6.9-11.ELsmp ([EMAIL PROTECTED]) (gcc version 3.4.3 20050227
(Red Hat 3.4.3-22)) #1 SMP Fri May 20 18:26:27 EDT 2005
bender:~/Zope-2.7.7-final$ python2.3
Python 2.3.5 (#1,
[Willi Langenberger]
Interesstingly, if i run the test with strace, i never see the test
fail (i tried at least 30 times):
[Jens Vagelpohl]
This sounds like something Tim had mentioned at one point, where
tests can fail on a machine that is too fast?
Dieter said that. I believe him, but it
[Dieter Maurer]
There is one essential thing you stress over and over again -- but
which I am not sure:
You say, the exception in tearDown means that
the test completed successfully -- without any error.
Oh no, that's not what I'm saying. As you say next,
However, I am
[Ricardo Newbery]
Oh so close...
Migrated from Zope 2.7.2 to 2.8.1
Updated all the Catalog instances according to the instructions.
Fixed a few outdated products.
Then just for kicks, I tried to update the Python scripts by visiting
the /manage_addProduct/PythonScripts/recompile url.
[Ricardo Newbery]
Oh so close...
Migrated from Zope 2.7.2 to 2.8.1
Updated all the Catalog instances according to the instructions.
Fixed a few outdated products.
Then just for kicks, I tried to update the Python scripts by visiting
the /manage_addProduct/PythonScripts/recompile url.
[michael nt milne]
...
Also does Zope 2.8 for linux have ZEO as standard.
All versions of Zope at and after 2.7 include ZEO, and regardless of
platform (Linux, Windows, Solaris, ..., doesn't matter).
___
Zope maillist - Zope@zope.org
[EMAIL PROTECTED]
Well, fortunatly I had last nights backup of the Data.fs. Restoring
that allowed Zope to be reverted to 2.7.7 and restart.
So here is my question.
Normally I have been able to upgrade Zope, and if the upgrade had
problems, revert to a prior version by simple redirecting
[garry saddington]
I have been using the zope 2.7 supplied with Debian Sarge but I have
noticed that the batching of ZSQL results using the ZSQL test tab is
broken. I get a missing object 'query'. So I thought I would install the
most recent stable Zope.
Which version is that? You mean in
http://zope.org/Products/Zope3/
[Reinoud van Leeuwen]
Is it intended that one should login before being able to access that
page?
Not intended, and logging in may not help either. Try it with and
without the trailing slash:
http://zope.org/Products/Zope3/
or
[Jens Vagelpohl]
Well, the question was actually What is the maximum size of this
file and/or maximum object ID? = just how many objects can the zodb
hold?. There is only a theoretical limit that has to do with the
largest index key for the ZODB index I believe, and that is some
ludicrously
[Tim Peters]
If you're using FileStorage, a technical detail in the implementation
of the FileStorage index limits the maximum file offset that can be
used to 2**48-1, or about 281 terabytes. Object IDs are effectively
64-bit integers (masquerading as 8-byte strings).
[Andreas Jung
[ [EMAIL PROTECTED]
My mistake, but given that, any sense if I can I safely ignore the
warning?
It's a DeprecationWarning. All it means is that Python's `whrandom`
module is going to go away in a future release -- it's advising
applications to switch to using the `random` module if they want
[Chris McDonough]
The symptom you're describing has happened to me in the past. Zope
stops serving requests and my CPU is not pegged (it's not hitting the
CPU hard via an infinept loop I've made). I usually end up tracking it
down to the fact that my instance is somehow leaking database
[Dieter Maurer]
...
I think, Tim wanted to implement such a keep alive mechanism
inside ClientStorage (to reliably detect disconnects) but
in ZODB 3.4 it seems not yet available.
Right on all counts: I would like to add that, because it's currently
possible for ZEO to run forever without
[Chris Wilton]
Whoops. Sorry.
Error log tells me it's a 'no space left on device' error:
2005-12-08T19:33:30 ERROR(200) SiteError
http://ekhidna.biocenter.helsinki.fi/dali/downloads/180M.tar/index_html
Traceback (most recent call last):
File
[Robert Conner]
Thanks for compiling that and setting up the windows installer.
However, I don't believe it works. Sorry it took me so long to get
back to you. I wanted to try installing this on a second computer
before I wrote back. On both of them it
What is it? Please spell out exactly
[Robert Conner]
Well color me purple, it does work.
Good! How could anything on Windows fail to work ;-)?
I was just so used to seeing the Zope Ready to handle Requests
message that when it never appeared I just assumed it was not working
at all. I've broken Zope on my computer 100 times
[Jonathan Cyr]
Where is the latest version of Repozo, the backup tool, kept?
Is there a reason, that it's not included with the Zope
install/utilities (at least the 2.7.x I'm using).
[... time passes ...]
Thanks for the quick response, I noticed that the my WinXP Zope
(sandbox) doesn't
[Cameron Beattie]
When I run the following:
python /usr/lib/zope/bin/zeopack.py -d 20 -h localhost -p 8100
I get an error:
No handlers could be found for logger ZEO.zrpc
As Dieter said, that's not an error in and of itself, it's just
Python's logging module whining at you. ZEO.zrpc is
[Gerhard Schmidt]
since three days we have problems when packing the Data.fs.
2006-01-25T03:40:42 ERROR(200) zrpc:7266 Error raised in delayed method
Traceback (most recent call last):
File /usr/local/www/Zope/lib/python/ZEO/StorageServer.py, line 991, in run
result =
[Dennis Allison]
We are (finally) moving to repozo for our backups. We are running a mixed
collection of Zopes -- mostly Zope 2.7.6, Zope 2.8.X and Zope 2.9.0. For
the near term we cannot move to a single release. There are differences
between the versions of repozo distributed with the
[P. Nagaraj]
[ZODB3-3.4.0]# python test.py
Running tests from build/lib.linux-i686-2.3
Running unit tests:
Error in test testUmask (zdaemon.tests.testzdrun.ZDaemonTests)
Traceback (most recent call last):
File build/lib.linux-i686-2.3/zdaemon/tests/testzdrun.py, line
75, in tearDown
I'm pleased to announce the release of ZODB 3.4 beta 1. This corresponds to
the ZODB that will ship in Zope 2.8b2. You can download a source tarball or
Windows installer from:
http://zope.org/Products/ZODB3.4
Note that there are two Windows installers, for Python 2.3 (2.3.5 is
recommended)
I'm pleased to announce the release of ZODB 3.4 final. This corresponds to
the ZODB that will ship in Zope 2.8. You can download a source tarball or
Windows installer from:
http://zope.org/Products/ZODB3.4
Note that there are two Windows installers, for Python 2.3 (2.3.5 is
recommended)
I'm pleased to announce the release of ZODB 3.4.1 final. This corresponds
to the ZODB that will ship in Zope 2.8.1. You can download a source tarball
or Windows installer from:
http://zope.org/Products/ZODB3.4
Note that there are two Windows installers, for Python 2.3 (2.3.5 is
I'm pleased to announce the release of ZODB 3.5.1 final. This corresponds
to the ZODB that will ship in Zope 3.1.0 final. You can download a source
tarball or Windows installer from:
http://zope.org/Products/ZODB3.5
Note that there are two Windows installers, for Python 2.3 (2.3.5 is
I'm pleased to announce the release of ZODB 3.4.2 final. This corresponds
to the ZODB in Zope 2.8.2 final. You can download a source
tarball or Windows installer from:
http://zope.org/Products/ZODB3.4
Note that there are two Windows installers, for Python 2.3 (2.3.5 is
recommended) and
I'm pleased to announce the release of ZODB 3.2.10 final. This corresponds
to the ZODB in Zope 2.7.8 final. You can download a source
tarball or Windows installer from:
http://zope.org/Products/ZODB3.2
Note that there are two Windows installers, for Python 2.3 (2.3.5 is
recommended) and
Update of /cvs-repository/Packages/ZODB/tests
In directory cvs.zope.org:/tmp/cvs-serv6932/ZODB/tests
Modified Files:
Tag: Zope-2_7-branch
MTStorage.py
Log Message:
The various flavors of the ``check2ZODBThreads`` and ``check7ZODBThreads``
tests are much less likely to suffer
Log message for revision 29892:
Temporarily point the ZODB code at current 3.4 branch.
That contains some of the changes from Jim's ZClasses branch.
The other changes still need to be merged into Zope, but require
using current ZODB code. Pointing at the 3.4 branch allows for
easy
[Sidnei da Silva]
Log message for revision 29977:
* Implement a file handler with 'rotate'. This closes the file, attempts
a rename to {filename}.last, then reopens the original name. This
then makes the log available for another process to perform the rotation
logic on. This
Update of /cvs-repository/Packages/ZEO
In directory cvs.zope.org:/tmp/cvs-serv30645
Modified Files:
Tag: Zope-2_7-branch
runzeo.py
Log Message:
Add platform idea of line terminator to pid file.
Compute the pidfile path only once.
=== Packages/ZEO/runzeo.py 1.15.6.6 = 1.15.6.7 ===
Mark and Sidnei, question for you. I work on ZRS, which, alas, I
can't pass out code for. Its Windows service drivers subclass the
Service class in Zope's nt_svcutils/service.py.
I'm trying to build a new ZRS release. Trying to stop the ZRS service
now suddenly and for no reason at all wink
[Mark Hammond]
[For some reason Tim's original still hasn't arrived!]
You know, from my POV that statement is pretty mysterious, since you
seem to be replying to my email here wink.
[Tim Peters]
...
I'm trying to build a new ZRS release. Trying to stop the ZRS service
now suddenly
Update of /cvs-repository/Zope/lib/python/nt_svcutils
In directory cvs.zope.org:/tmp/cvs-serv16208/lib/python/nt_svcutils
Modified Files:
Tag: Zope-2_7-branch
service.py
Log Message:
After consulting with Mark Hammond, removed the explicit calls to SvcStop().
That method gets
Update of /cvs-repository/Packages/ZEO
In directory cvs.zope.org:/tmp/cvs-serv20696/ZEO
Modified Files:
Tag: Zope-2_7-branch
ServerStub.py
Log Message:
DemoStorage: Added implementations for registerDB() and new_oid(). As
Tres discovered the hard way, wrapping a ZEO client
Update of /cvs-repository/Packages/ZODB
In directory cvs.zope.org:/tmp/cvs-serv20696/ZODB
Modified Files:
Tag: Zope-2_7-branch
BaseStorage.py DemoStorage.py
Log Message:
DemoStorage: Added implementations for registerDB() and new_oid(). As
Tres discovered the hard way, wrapping a
Log message for revision 30171:
Move to ZODB 3.4a5, which fixes some problems in the new savepoint features.
Changed:
_U Zope/trunk/lib/python/
_U Zope/trunk/utilities/
-=-
Property changes on: Zope/trunk/lib/python
___
Update of /cvs-repository/Packages/ZEO
In directory cvs.zope.org:/tmp/cvs-serv21065/ZEO
Modified Files:
Tag: Zope-2_7-branch
__init__.py version.txt
Log Message:
Mechanical changes for the 3.2.7 final release.
=== Packages/ZEO/__init__.py 1.19.4.22 = 1.19.4.23 ===
---
Log message for revision 30197:
Install these file types from the Zope3 code:
*.rst
*.request
*.response
That fixes two of the test failures when running from a
WinBuilders build directory. Two others have been failing since
last October. That leaves one:
Log message for revision 30198:
Install the oddball 'png' (no extension!) file from
zope/app/publisher/browser/tests/testfiles/. This
required adding a one-shot mechanism to Finder.visit().
The only tests that fail from a WinBuilders build/
directory now are the two that have been
Update of /cvs-repository/Packages/ZopeUndo/tests
In directory cvs.zope.org:/tmp/cvs-serv17930/ZopeUndo/tests
Modified Files:
Tag: Zope-2_7-branch
testPrefix.py
Log Message:
Turns out the change snuck into ZopeUndo.Prefix created critical
ZEO compatibility bugs. This will force a
Update of /cvs-repository/Packages/ZODB
In directory cvs.zope.org:/tmp/cvs-serv18683/ZODB
Modified Files:
Tag: Zope-2_7-branch
__init__.py
Log Message:
Part of the changes needed to make a 3.2.8 release. I need to find
another machine to build updated docs.
===
Update of /cvs-repository/Packages/ZEO
In directory cvs.zope.org:/tmp/cvs-serv18683/ZEO
Modified Files:
Tag: Zope-2_7-branch
__init__.py version.txt
Log Message:
Part of the changes needed to make a 3.2.8 release. I need to find
another machine to build updated docs.
===
[Andreas Jung]
Log message for revision 30205:
- Collector #1233: ported ZOPE_CONFIG patch from Zope 2.7 to Zope 2.8
Changed:
U Zope/trunk/doc/CHANGES.txt
U Zope/trunk/lib/python/Zope2/Startup/options.py
U Zope/trunk/lib/python/Zope2/__init__.py
test.py doesn't work at all
Log message for revision 30313:
Move to ZODB 3.4a8. This implements the other half of
moving ZApplication.py from ZODB into Zope(2).
Changed:
_U Zope/trunk/lib/python/
_U Zope/trunk/utilities/
-=-
Property changes on: Zope/trunk/lib/python
Log message for revision 30350:
Move to ZODB 3.4a9.
Among other things, contains fixes for longstanding
off-by-1 errors in undoLog() and undoInfo().
Changed:
_U Zope/trunk/lib/python/
_U Zope/trunk/utilities/
-=-
Property changes on: Zope/trunk/lib/python
Log message for revision 30444:
Move to ZODB 3.4b1.
Changed:
_U Zope/trunk/lib/python/
_U Zope/trunk/utilities/
-=-
Property changes on: Zope/trunk/lib/python
___
Name: svn:externals
- zope
Log message for revision 30543:
Use a properly constructed tag for the Zope3 code.
Changed:
_U Zope/branches/Zope-2_8-branch/lib/python/
-=-
Property changes on: Zope/branches/Zope-2_8-branch/lib/python
___
Name:
Update of /cvs-repository/Packages/ZODB
In directory cvs.zope.org:/tmp/cvs-serv13892/ZODB
Modified Files:
Tag: Zope-2_7-branch
referencesf.py
Log Message:
referencesf(): Use %r instead of %s format in the error message, else
the pickle shown is full of unprintable characters.
Log message for revision 30636:
Move to ZODB 3.4c1.
Changed:
_U Zope/branches/Zope-2_8-branch/lib/python/
_U Zope/branches/Zope-2_8-branch/utilities/
-=-
Property changes on: Zope/branches/Zope-2_8-branch/lib/python
___
Log message for revision 30638:
Merge rev 30636 from Zope-2_8-branch.
Move to ZODB 3.4c1.
Changed:
_U Zope/trunk/lib/python/
_U Zope/trunk/utilities/
-=-
Property changes on: Zope/trunk/lib/python
___
Name:
Log message for revision 30646:
While nothing should ever be checked in on a tag directly,
2.8b2 was already released for non-Windows, but contains an
incorrect Zope version number in the Windows buildout. Since
a Windows installer was never released for 2.8b2 (I'm trying
to do that
Log message for revision 30651:
Port critical Windows fix from the 2.7 branch.
I hate checking into a tag, but 2.8's Windows release
process has been dying from neglect, and I don't see
a saner way to proceed. The 2.8b2 Windows installer
on zope.org was effectively built from this
Log message for revision 30652:
Merge critical Windows fix from Zope/tags/Zope-2-8-0-b2, rev 30651.
Mark Hammond's original checkin comment:
As at pywin32-204, we must ensure pywintypes is the first win32 module
imported in our process, otherwise we can end up with 2 pywintypesxx.dll
Log message for revision 30653:
Merge critical Windows fix from Zope/tags/Zope-2-8-0-b2, rev 30651.
Mark Hammond's original checkin comment:
As at pywin32-204, we must ensure pywintypes is the first win32 module
imported in our process, otherwise we can end up with 2 pywintypesxx.dll
Log message for revision 30663:
Move to ZODB 3.4c2.
Changed:
_U Zope/branches/Zope-2_8-branch/lib/python/
_U Zope/branches/Zope-2_8-branch/utilities/
-=-
Property changes on: Zope/branches/Zope-2_8-branch/lib/python
___
Log message for revision 30667:
Merge rev 30663 from 2.8 branch.
Move to ZODB 3.4c2.
Changed:
_U Zope/trunk/lib/python/
_U Zope/trunk/utilities/
-=-
Property changes on: Zope/trunk/lib/python
___
Name: svn:externals
Log message for revision 30689:
Merge rev 30688 from 2.8 branch.
Import pywintypes first.
Mark Hammond's checkin comment for Zope 2.7's WinSignalHandler.py,
rev 1.1.2.2:
As at pywin32-204, we must ensure pywintypes is the first win32 module
imported in our process,
Log message for revision 30721:
Move to ZODB 3.4 and zdaemon 1.1.
Changed:
_U Zope/branches/Zope-2_8-branch/lib/python/
_U Zope/branches/Zope-2_8-branch/utilities/
-=-
Property changes on: Zope/branches/Zope-2_8-branch/lib/python
Log message for revision 30725:
Merge rev 30721 from 2.8 branch.
Move to ZODB 3.4 and zdaemon 1.1.
Changed:
_U Zope/trunk/lib/python/
_U Zope/trunk/utilities/
-=-
Property changes on: Zope/trunk/lib/python
___
Name:
Log message for revision 30774:
ZOPEVERSION didn't match the name of the tarball ==
the name of the tarball's top-level directory. This
prevented making a Windows installer from the 2.8.0
tag.
Changed:
U Zope/tags/Zope-2-8-0/inst/WinBuilders/mk/zope.mk
-=-
Modified:
1 - 100 of 513 matches
Mail list logo
