Tim Peters wrote:
Log message for revision 41291:
Pain, pain, and more pain.
The build-the-installer process now completes, and running
the installer creates something that may or may not be a
working Zope. It starts fine as a Windows Service, and at
least looks like a Zope
Summary of messages to the zope-tests list.
Period Thu Jan 12 12:01:01 2006 UTC to Fri Jan 13 12:01:01 2006 UTC.
There were 8 messages: 8 from Zope Unit Tests.
Tests passed OK
---
Subject: OK : Zope-2_6-branch Python-2.1.3 : Linux
From: Zope Unit Tests
Date: Thu Jan 12 21:01:50 EST
Andreas Jung wrote:
Thoughts?
All these changes seem to be the right thing. This will make unicode
life in Zope a lot easier.
I worry about backward compatibility though.
Some code (such as PlacelessTranslationService) is doing wild things
like monkeypatching the ZPT engine so that
Andreas Jung wrote:
--On 5. Januar 2006 12:47:20 +0100 Andreas Jung [EMAIL PROTECTED]
wrote:
As you might know I worked on the integration of the Zope 3 ZPT
implementation for Zope 2.10. Before commiting the changes to the trunk I
would like discuss my approach for Zope 2.10
I forgot to
--On 13. Januar 2006 13:25:19 +0100 Martijn Faassen [EMAIL PROTECTED]
wrote:
Andreas Jung wrote:
Thoughts?
All these changes seem to be the right thing. This will make unicode life
in Zope a lot easier.
I worry about backward compatibility though.
Some code (such as
Andreas Jung schrieb:
...
Now, if I have code that takes something from that request and displays
it in a unicode page template, you'd have a problem, as you'd be mixing
UTF-8 with unicode there. Again this might result in a lot of broken
code.
I share your worries (meanwhile :-)).
The Buildbot has detected a failed build of Zope branches 2.9 2.4 Linux
zc-buildbot.
Buildbot URL: http://buildbot.zope.org/
Build Reason: changes
Build Source Stamp: 2750
Blamelist: andreasjung,anguenot,efge,mkerrin,oestermeier,tim_one,ykomatsu
BUILD FAILED: failed test
sincerely,
-The
The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot.
Buildbot URL: http://buildbot.zope.org/
Build Reason: changes
Build Source Stamp: 2751
Blamelist: andreasjung,efge,tim_one,ykomatsu
BUILD FAILED: failed test
sincerely,
-The Buildbot
[Sidnei da Silva]
Way to go Tim! You beat me to it. I was supposed to look at this soon
but got back from vacation just this tuesday. I will make sure your
installer gets testing and try to fix any eventual issues.
Excellent! This may actually work ;-)
While I'll be on vacation the next two
[Philipp von Weitershausen]
It seems that 'inst' holds nothing of value anymore except 'Makefile.in'
and 'WinBuilders'.
WRT Windows, that's certainly true on my Windows-installer branch. I
don't know whether any of it is still useful on Linux. You seem to
think Makefile.in is still useful,
On Fri, Jan 13, 2006 at 03:13:17PM -0500, Tim Peters wrote:
| I'd rather just remove the decoys. The process of building a Windows
| installer needs/creates three not-checked-in directories that are
| siblings of WinBuilders, and it's nicer to have those hiding under
| inst/ than cluttering the
[Sidnei da Silva]
I think there's a Makefile.win too, that is used by inst/configure.py
on Windows. (I know because use it).
There is a Makefile.win.in, but the build-the-Windows-installer
process no longer uses it on my branch -- the branch doesn't use
anything in the root of inst/ anymore,
Andreas Jung wrote at 2006-1-10 11:23 +0100:
...
Do we need one for Zope 2 and Zope 3?
I think what we discussed during breakfast would be optimal:
To configure the Python logger such that:
* it supports additional (Zope2/3 standard!) log levels
* displays Zope tracebacks rather
Andreas Jung wrote at 2006-1-9 18:06 +0100:
...
I've never had the need to use them. That's different from not wanting to
use them. The more choice you have, the more trouble you have. I agree that
a TRACE level might be of interest. But BLATHER and PROBLEM is competely
overhead from my point of
[EMAIL PROTECTED] wrote:
I'm pretty sure this works.
Ok, I get it now. I misread it the first time.
This returns the equivalent of running
self.objectIds(spec=self._mt_index.keys()) on the current
trunk/release code, which should be identical to
self._tree.keys(), but much, much
Tim Peters wrote:
It seems that 'inst' holds nothing of value anymore except 'Makefile.in'
and 'WinBuilders'.
WRT Windows, that's certainly true on my Windows-installer branch. I
don't know whether any of it is still useful on Linux. You seem to
think Makefile.in is still useful, but if
16 matches
Mail list logo
