Hi Dieter
It describes a configuration option for your storage subsections
of the zodb_db sections in your Zope configuration file.
Yes, that's what I understood -- thank you!
What I meant was that few people seem to use this functionality, as
the outdated howtos stand uncorrected, and the
Hello,
I'm trying to find out how to generate a CSR, and I can't find the
information I need. All my research covers Zope and Apache or Zope and
Linux, etc., but our server is running ONLY Zope. Version 2.6.2, to be
exact. Unfortunately, I know next to nothing about setting up a secure
server
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Catherine,
well.. I don't have much experience running SSL on Zope itself, but
we use Apache in front and that works well.
You'll just have to figure out some RewriteRule directives for
Apache and configure it. Most SSL providers (that I've seen
Cat,
I'm trying to find out how to generate a CSR, and I can't find the
information I need.
If you are trying to generate a CSR, you probably need to use OpenSSL,
not Zope. If your *Zope application* needs to generate a CSR for some
reason, you need to interface OpenSSL from Zope somehow -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 16.03.2009 1:17 Uhr, Martin Aspeli wrote:
Andreas Jung wrote:
As mentioned earlier: use buildout. easy_install support has no high
priority right now.
Whilst I understand that we don't have the capacity to test all
different
Andreas Jung wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 16.03.2009 1:17 Uhr, Martin Aspeli wrote:
Andreas Jung wrote:
As mentioned earlier: use buildout. easy_install support has no high
priority right now.
Whilst I understand that we don't have the capacity to test all
Previously Stephan Richter wrote:
On Sunday 15 March 2009, Wichert Akkerman wrote:
If the package does not work with an older version of zope.publisher
than imho that version restriction *has* to be in setup.py.
And what if I backport the fix?
We have done version specification like
Am 15.03.2009 um 23:47 schrieb Roger Ineichen:
Hi Michael
Can you explain why you implemented the login viewlets?
The login in zope.app.security is implemented using browser pages and
metal-macros and is not really customizable. I needed a login/logout
which works fine with pagelets and
Am 16.03.2009 um 03:33 schrieb Stephan Richter:
On Sunday 15 March 2009, Wichert Akkerman wrote:
If the package does not work with an older version of zope.publisher
than imho that version restriction *has* to be in setup.py.
And what if I backport the fix?
In this case it was not a little
Hi,
I *think* this is a bug in zc.relationship, but I'm not quite sure.
I'm using ZODB3 3.8.1 (to get BLOB support) and trying to install
plone.app.relations, which depends on zc.relationship 1.0.2. In
particular, it subclasses zc.relationship.shared.Container, and stores
a
Am 16.03.2009 um 03:53 schrieb Roger Ineichen:
Hi Stephan, Wichert, Michael
Betreff: Re: [Zope3-checkins] [Checkins]
SVN:zope.app.component/trunk/setup.py set missing minimum version
On Sunday 15 March 2009, Wichert Akkerman wrote:
If the package does not work with an older version of
Summary of messages to the zope-tests list.
Period Sun Mar 15 12:00:00 2009 UTC to Mon Mar 16 12:00:00 2009 UTC.
There were 6 messages: 6 from Zope Tests.
Unknown
---
Subject: UNKNOWN : Zope-trunk-alltests Python-2.4.6 : Linux
From: Zope Tests
Date: Sun Mar 15 21:32:24 EDT 2009
URL:
On Mar 16, 2009, at 4:02 AM, Martin Aspeli wrote:
Hi,
I *think* this is a bug in zc.relationship, but I'm not quite sure.
I'm using ZODB3 3.8.1 (to get BLOB support) and trying to install
plone.app.relations, which depends on zc.relationship 1.0.2. In
particular, it subclasses
Gary Poster wrote:
On Mar 16, 2009, at 4:02 AM, Martin Aspeli wrote:
Hi,
I *think* this is a bug in zc.relationship, but I'm not quite sure.
I'm using ZODB3 3.8.1 (to get BLOB support) and trying to install
plone.app.relations, which depends on zc.relationship 1.0.2. In
particular, it
Martin Aspeli wrote:
Gary Poster wrote:
On Mar 16, 2009, at 4:02 AM, Martin Aspeli wrote:
Hi,
I *think* this is a bug in zc.relationship, but I'm not quite sure.
I'm using ZODB3 3.8.1 (to get BLOB support) and trying to install
plone.app.relations, which depends on zc.relationship 1.0.2.
On Mar 16, 2009, at 8:39 AM, Martin Aspeli wrote:
Gary Poster wrote:
On Mar 16, 2009, at 4:02 AM, Martin Aspeli wrote:
Hi,
I *think* this is a bug in zc.relationship, but I'm not quite sure.
I'm using ZODB3 3.8.1 (to get BLOB support) and trying to install
plone.app.relations, which
Hi Gary,
zc.relationship 2.0 trunk is now essentially a wrapping of zc.relation
code for backwards compatibility.
I see. But 2.0dev on pypi isn't?
What's the story behind zc.relation and the evolution of zc.relationship?
You guys are the main clients for zc.relationship at this point, I
Hey,
Tres Seaver wrote:
[snip]
Doesn't that in some cases make tests harder to understand, as
lower-level APIs are in use that are not as recognizable as the
equivalent ZCML directives? (say, registering an event) Don't we place a
burden on the test writers to learn these APIs while they
On Mar 16, 2009, at 9:19 AM, Martin Aspeli wrote:
Hi Gary,
zc.relationship 2.0 trunk is now essentially a wrapping of
zc.relation
code for backwards compatibility.
I see. But 2.0dev on pypi isn't?
What's the story behind zc.relation and the evolution of
zc.relationship?
Briefly, I
Hey,
Dan Korostelev wrote:
[snip]
Thinking now. If we want local persistent permissions to be considered
dead and we want to discourage their usage, may be the package should
be called zope.app.localpermission then? If so, we could also move
its ZMI views there and forget about that package.
Hey Dan,
Thanks for doing the great work and thanks for this summary. Go Dan!!
Could you update our upgrade_notes in the Zope Framework documentation
with a sketch of your work here? My work is that eventually we can
aggregate information from our changelogs to create a similar document
from
Stephan Richter wrote:
On Friday 13 March 2009, Dan Korostelev wrote:
2009/3/13 Dan Korostelev nad...@gmail.com:
The refactoring of zope.app.security is now generally done. In the
process, three new packages has been created:
[snip]
Please, check it out and say your opinion. I'd like new
Hey Dan,
You bring up another great topic!
Dan Korostelev wrote:
One of most annoying dependencies is the zope.app.appsetup package.
Some packages, like zope.session depend on it just to provide
boostrap setup for using these packages in context of zope3, the
application server, however,
Hey Christian,
Thanks for picking up on this discussion.
Christian Theune wrote:
[snip]
It might be a goal to get rid of all of zope.app with respect to the
Zope Framework definition.
Our *goal* is not to have any zope.app package within the framework.
zope.app should be useful for Zope 3 as
Christian Theune wrote:
On Tue, 2009-03-03 at 01:33 +0100, Martijn Faassen wrote:
[a possible role for WebOb in the Zope Framework]
@Martijn:
This thread somewhat overlapped with the forming of the steering group.
Do you think this should go to the list of open issues?
Yes. I've just
Hi Gary,
Thanks for being so helpful!
What's the difference between 1.1.1 and 2.0dev on pypi?
I intended that 1.1.1 would simply make the absolutely minimal changes
necessary for you to be able to use the 1.1 branch. It would not have
any of the 2.x changes at all.
But we're saying
Stephan Richter wrote:
On Sunday 15 March 2009, Wichert Akkerman wrote:
If the package does not work with an older version of zope.publisher
than imho that version restriction *has* to be in setup.py.
And what if I backport the fix?
We have done version specification like this in the Zope
On Mar 16, 2009, at 10:21 AM, Martin Aspeli wrote:
Hi Gary,
Thanks for being so helpful!
Happy to.
What's the difference between 1.1.1 and 2.0dev on pypi?
I intended that 1.1.1 would simply make the absolutely minimal
changes
necessary for you to be able to use the 1.1 branch. It
On Monday 16 March 2009, Martijn Faassen wrote:
On a related note: I noticed that you earlier released some packages as
a bugfix release even though they had been undergoing some dependency
refactoring. I think we want to err on the side of caution an always do
a feature release (x.y instead
On Mon, Mar 16, 2009 at 10:24 AM, Martijn Faassen
faas...@startifact.com wrote:
Stephan Richter wrote:
On Sunday 15 March 2009, Wichert Akkerman wrote:
If the package does not work with an older version of zope.publisher
than imho that version restriction *has* to be in setup.py.
And what if
On Monday 16 March 2009, Martijn Faassen wrote:
I'm not sure I agree you here, Stephan. A possible disagreement within
the steering group, how interesting! :)
:-)
The most widely open requirement is this:
zope.foo
but another open requirement is this:
zope.foo = 1.3
Sure, but here is
On Monday 16 March 2009, Martijn Faassen wrote:
I saw that, on last sprint, the subscriber for error reporting utility
was moved from zope.error to zope.app.appsetup, so zope.error could
lose the dependency on zope.app.appsetup. So, the first question is:
do we want to move all subscribers
Hi
Betreff: Re: [Zope-dev] setting missing minimum version in setup.py
On Monday 16 March 2009, Martijn Faassen wrote:
I'm not sure I agree you here, Stephan. A possible
disagreement within
the steering group, how interesting! :)
:-)
The most widely open requirement is this:
Hi Michael
Betreff: Re: AW: [Checkins] SVN: z3c.layer.pagelet/trunk/
Removed dependency on``zope.app.security`` by using the new
packages``zope.authentication`` and ``zope.principalregistry``.
Am 15.03.2009 um 23:47 schrieb Roger Ineichen:
Hi Michael
Can you explain why you
Hey,
Stephan Richter wrote:
[snip]
There is a compromise I am willing to take. If package zope.bar depends on a
*new feature* or *feature change* in zope.foo 1.3.x, then it should specify
the version. In other words specifying open restrictions on the major version
levels is okay, but
Hey,
Roger Ineichen wrote:
[snip]
Even if it's rare, why should we not support that?
The consequence of fixing versions is to skip backporting.
There is no way to have both. Are you really sure we like to
skip backporting.
I haven't a clear idea about how often we backport and even less an
2009/3/16 Martijn Faassen faas...@startifact.com:
There is a compromise I am willing to take. If package zope.bar depends on a
*new feature* or *feature change* in zope.foo 1.3.x, then it should specify
the version. In other words specifying open restrictions on the major version
levels is
Am 16.03.2009 um 16:43 schrieb Roger Ineichen:
[...]
It's a pagelet implementation of login/logout, so I thought
it matches the goal of this package very well.
Yes and No. It's of corse usefull to have predefined login
views available. But I use a z3c.form based implementation
for this.
I
On Mar 16, 2009, at 12:05 PM, Dan Korostelev wrote:
2009/3/16 Martijn Faassen faas...@startifact.com:
There is a compromise I am willing to take. If package zope.bar
depends on a
*new feature* or *feature change* in zope.foo 1.3.x, then it
should specify
the version. In other words
2009/3/16 Michael Howitz m...@gocept.com:
Am 16.03.2009 um 16:43 schrieb Roger Ineichen:
[...]
It's a pagelet implementation of login/logout, so I thought
it matches the goal of this package very well.
Yes and No. It's of corse usefull to have predefined login
views available. But I use a
Am 16.03.2009 um 15:49 schrieb Benji York:
[...]
I don't like version requirements in setup.py because they assume too
much about how people are using the package.
Lets say that someone adds two bug fixes to zope.foo (call them fix A
and fix B) and then does a release. Fix A requires
Am 16.03.2009 um 16:56 schrieb Martijn Faassen:
Hey,
Stephan Richter wrote:
[snip]
There is a compromise I am willing to take. If package zope.bar
depends on a
*new feature* or *feature change* in zope.foo 1.3.x, then it should
specify
the version. In other words specifying open
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andreas Jung wrote:
On 16.03.2009 4:52 Uhr, Tres Seaver wrote:
Andreas Jung wrote:
On 15.03.2009 18:42 Uhr, Tres Seaver wrote:
Original Message
Subject: [Bug 343079] [NEW] Broken distribution (2009-03-15)
Date: Sun, 15 Mar 2009
Previously Martijn Faassen wrote:
Hey,
Stephan Richter wrote:
[snip]
There is a compromise I am willing to take. If package zope.bar depends on
a
*new feature* or *feature change* in zope.foo 1.3.x, then it should specify
the version. In other words specifying open restrictions on
Tres Seaver wrote:
Andreas Jung wrote:
Please look at the getPackages() method taking the version*cfg files
into account. So all versions should be pinned. However there is
obviously a difference between using buildout with pinned versions
and setuptools or a small undetected hole in the
Am 12.03.2009 um 19:25 schrieb Tres Seaver:
[...]
Now when testing these libraries you could do three things:
* not use ZCML at all and recreate the effect of these
registrations in
Python code.
+1.
* use the ZCML in the package's configure.zcml. (perhaps through
ftesting.zcml)
-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Hey,
Tres Seaver wrote:
[snip]
Doesn't that in some cases make tests harder to understand, as
lower-level APIs are in use that are not as recognizable as the
equivalent ZCML directives? (say, registering an event)
Am 11.03.2009 um 21:26 schrieb Dan Korostelev:
2009/3/11 Martijn Faassen faas...@startifact.com:
Oh, and on the topic, one more time: can we have a steering group
decision on the package requirements for zcml statements? Are we
doing
extras for them or simply skipping them?
Sorry, I
Gary Poster wrote:
Hopefully. Do we know that zc.relationship 1.1 works with both ZODB
versions?
That would be a significant point of its existence, so I certainly
hope so. I'm 80%+ confident that it does, and would regard not
supporting 3.7 as a bug that I'd be willing to fix.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 16.03.2009 17:40 Uhr, Hanno Schlichting wrote:
Tres Seaver wrote:
Andreas Jung wrote:
Please look at the getPackages() method taking the version*cfg files
into account. So all versions should be pinned. However there is
obviously a difference
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 16.03.2009 17:21 Uhr, Tres Seaver wrote:
Maybe generating indexes from the varios known good metadata we are
already maintaining would be the right path.
By index you refer to a KGS or a release-specific directory containing
the blessed
Martin Aspeli wrote:
Gary Poster wrote:
Hopefully. Do we know that zc.relationship 1.1 works with both ZODB
versions?
That would be a significant point of its existence, so I certainly
hope so. I'm 80%+ confident that it does, and would regard not
supporting 3.7 as a bug that I'd be
On Mar 16, 2009, at 1:20 PM, Martin Aspeli wrote:
Martin Aspeli wrote:
Gary Poster wrote:
Hopefully. Do we know that zc.relationship 1.1 works with both ZODB
versions?
That would be a significant point of its existence, so I certainly
hope so. I'm 80%+ confident that it does, and would
Wichert Akkerman wrote:
Previously Martijn Faassen wrote:
Hey,
Stephan Richter wrote:
[snip]
There is a compromise I am willing to take. If package zope.bar depends on
a
*new feature* or *feature change* in zope.foo 1.3.x, then it should specify
the version. In other words
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andreas Jung wrote:
On 16.03.2009 17:21 Uhr, Tres Seaver wrote:
Maybe generating indexes from the varios known good metadata we are
already maintaining would be the right path.
By index you refer to a KGS or a release-specific directory
2009/3/16 Michael Howitz m...@gocept.com:
zope.container has a similar problem: its configure.zcml uses zope:view
directives. When I'd like to use zope.container in a Zope 3 the application
server environment I have to know that zope:view is defined in
zope.app..component or I have to find it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hanno Schlichting wrote:
Tres Seaver wrote:
Andreas Jung wrote:
Please look at the getPackages() method taking the version*cfg files
into account. So all versions should be pinned. However there is
obviously a difference between using buildout
Hi Tres,
Tres Seaver schrieb:
For instance, if we provided for each mega-framework a single
everything {Grok,Zope2,Zope3ZMI} needs from the Zope framework
package, which named all the appropriate dependencies *and* provided the
shared ZCML, and then switched each mega-framework and its
Hi all
I run my script foo.zctl with zopectl run foo.ctl param1 param2.
This script operates on a large ZODB and catches ConflictErrors
accordingly. It iterates over a set, updates data and commits the
transaction every 100 iterations. But I've noticed two things:
1. ConflictErrors are never
Gary Poster wrote:
Yes, +1. Thank you. I was about to write to your other message that
this was quite possibly the only 3.8 dependency.
Cool. Committed.
If we do that, then we can let plone.relations depend on
zc.relationship
1.1.1 explicitly and have support for both ZODB versions,
60 matches
Mail list logo
