On 06.09.2012, at 10:58, Marius Gedminas wrote:
How do you redirect the stderr of a process spawned with
suprocess.Popen(shell=False) to /dev/null in a cross-platform manner?
os.devnull perhaps? Or rather, what about subprocess.Popen(cmd,
stderr=subprocess.PIPE)?
Stefan
--
Stefan H. Holek
to an HTTP return header.
___
checkins mailing list
check...@zope.org
https://mail.zope.org/mailman/listinfo/checkins
--
Stefan H. Holek
ste...@epy.co.at
___
Zope-Dev maillist - Zope-Dev@zope.org
https
:00 2010 UTC.
There were no messages.
Eeek. Something broken?
--
Stefan H. Holek
ste...@epy.co.at
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists
Solis
--
Stefan H. Holek
ste...@epy.co.at
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
are borken in python
2.4, because it doesn't have Py_ssize_t.
--
Stefan H. Holek
ste...@epy.co.at
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https
: FAILED (failures=7) : Zope-trunk-alltests Python-2.6.2 :
Linux
From: Zope Tests
Date: Fri Jul 17 20:58:01 EDT 2009
URL: http://mail.zope.org/pipermail/zope-tests/2009-July/012086.html
--
Stefan H. Holek
ste...@epy.co.at
___
Zope-Dev maillist
What's the reason zope.component.interfaces has no BBB for this
import? The Zope Toolkit is full of 'deprecated()', so why not in this
case?
Stefan
On 27.04.2009, at 03:28, CMF Tests wrote:
CMF Tests : UNKNOWN
CMF-trunk Zope-trunk Python-2.6.1 : Linux
Running
Do we still care about Python 2.4 + Zope 2.12? Do we go Python 2.6 only?
Thanks,
Stefan
On 20.04.2009, at 14:00, Zope Tests Summarizer wrote:
Summary of messages to the zope-tests list.
Period Sun Apr 19 12:00:00 2009 UTC to Mon Apr 20 12:00:00 2009 UTC.
There were 8 messages: 8 from Zope
For the time being Zope2 must be used as a develop egg. Like e.g. so:
http://svn.zope.org/CMF.buildout/trunk/
Stefan
On 13.02.2009, at 13:49, Chris Withers wrote:
I guess this equates to what does a Zope 2 instance look like now
that
we're buildout-based?
I don't think you faired that badly. ;-)
One obvious problem is the removal of the 'defaultSkin' directive,
which is still in use by CMFDefault. The rest looks harmless.
I am not opposed to ditching the trunk, but I don't think keeping it
in sync (if only for a transition period) is
While we are at it...
The biggest offender is the zodbcode package, which does not appear to
pass its tests at all under Python 2.6. Not having investigated this
further I can imagine three courses of action:
1) Fix zodbcode (me shrugs)
2) Exclude zodbcode tests from the test suite
Enough!
I have put a copy of docutils-0.4.tar.gz on the test server and point
buildout at it via ~/.buildout/default.cfg.
Stefan
On 19.01.2009, at 02:55, Zope Tests wrote:
Zope Tests : UNKNOWN
Zope[2.buildout]-trunk Python-2.5.2 : Linux
Running /usr/local/python2.5/bin/python ./bin/test
That test seems to be timing out both yesterday and today trying to
download docutils: do you think having the buildout use a
download_cache would help?
Tres.
It certainly would. I am however reluctant to enable the download
cache because it may mask incomplete buildout configurations.
Up it may be, working it is not. E.g.:
Fetching external item into 'python24-zope210/lib/python/zope/testing'
svn: Reference to non-existent node 'd2u.9gw.r70272/0' in filesystem
'/svn/repos/main/db'
Fetching external item into 'python24-zope211/lib/python/zope/decorator'
A
The Python 2.3 on that box hasn't changed in a while, and the
encodings module works, at least interactively.
$ /usr/local/python2.3/bin/python
Python 2.3.6 (#1, Nov 11 2006, 11:08:56)
[GCC 4.0.2 (Debian 4.0.2-2)] on linux2
Type help, copyright, credits or license for more information.
import
What I have found out now is that in my Python 2.3.6 encodings/
__init__.py does not contain 'import aliases' at module level,
whereas the Python 2.4 lib has this import. The patch does this:
import encodings
encodings._aliases = encoding.aliases.aliases
which does therefore not work in 2.3.
It is a hand-compiled Python 2.3, not the one coming with the
distro. I'll have to look into it, maybe ./configure missed something...
Stefan
On 20. Aug 2008, at 19:57, Tres Seaver wrote:
Tests are blowing up on that box becaues the 'encodings' module has no
attribute 'aliases': AFAICT,
configuration.
--
Stefan H. Holek
[EMAIL PROTECTED]
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
I'd like to sneak the following patch into 2.11 before final. The
idea is that zope.conf option names should use dashes and not
underscores. The downside is that it will break all zope.conf files
that already use this option.
Objections?
Stefan
+Bugs Fixed
+
+ - Fixed
://mail.zope.org/pipermail/zope-tests/2008-May/009619.html
--
Stefan H. Holek
[EMAIL PROTECTED]
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http
+1 for trunk
-1 for 2.11 branch
Stefan
On 25. Apr 2008, at 20:49, Tres Seaver wrote:
I'd like to rip out the old Interface module from the 2.11 branch and
the trunk, along with all the useless decoys which import it.
--
Anything that happens, happens. --Douglas Adams
On 17.04.2008, at 12:27, Hanno Schlichting wrote:
Opinions, votes?
+1
--
Stefan H. Holek
[EMAIL PROTECTED]
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding
On 17. Nov 2007, at 02:15, Martin Aspeli wrote:
I understand the historical reasons behind these dependencies, but
I genuinely think we should pick a few libraries that are useful
to the outside world (zope.interface, zope.component,
zope.configuration, zope.annotation, zope.event come to
I have put all of ZopeTestCase on a test layer, making it possible to
mix ZTC and non-ZTC tests more freely. The layer is currently
available on the Zope 2 trunk (2.11) only.
You can read more here:
http://www.zope.org/Members/shh/ZopeTestCaseWiki/ZopeLiteLayer
Stefan
--
Anything that
I may be missing something here, but the fact that you have to use
POST is fully intentional and not a bug.
Stefan
On 5. Jul 2007, at 11:27, Jonas Meurer wrote:
When do you plan to add the fix for request must be post at Take
Ownership to a stable zope 2.10 release? It seems like this bug
I plan to land the ZopeLite* layer work for 2.11. It's already
running fine in my sandbox but has some implications for existing
tests in both Zope and CMF, which I at least need to document. Do you
have a target date for 2.11?
Stefan
(*) ZopeTestCase magic deferred to layer setup time
FWIW, I have parked the fix on a branch [1][2] and will wait for Zope
2.9.8 [3].
Stefan
[1] http://svn.zope.org/Products.Five/?rev=76908view=rev
[2] http://svn.zope.org/Products.Five/?rev=76909view=rev
[3] http://mail.zope.org/pipermail/zope-dev/2007-June/029454.html
On 21. Jun 2007, at
for IObjectManager that directly calls
# dispatchToSublocations.
Cheers,
Stefan
On 20. Jun 2007, at 12:25, Philipp von Weitershausen wrote:
Stefan H. Holek wrote:
Log message for revision 76597:
Collector #2307: ObjectCopiedEvent not dispatched to sublocations.
...
@@ -130,7 +131,15
This should of course have read: I took my cues from how
*ObjectMovedEvent* is handled.
On 20. Jun 2007, at 13:16, Stefan H. Holek wrote:
I took my cues from how ObjectModifiedEvent is handled. I figured
copied and moved should be treated the same. Also, there is this
comment in OFS
Most ObjectEvents are dispatched to sublocations. I was wondering
whether it is ok for me to expect a certain dispatch order, i.e. top-
down (container before sublocation) or bottom-up (sublocation before
container)?
What I find is that this order depends on things like the exact
Thanks!
On 10. Apr 2007, at 18:34, Philipp von Weitershausen wrote:
No. The dispatch to sublocations is an event handler itself. One
should not depend on the execution order of event handlers,
therefore you should not depend on this dispatch happening before
or after your own event
The buildbot for Zope 2 won't ever complete successfully unless
ZODB.tests.testZODB.checkResetCachesAPI is excluded from the test
run. The bot's command line should look something like:
python2.4 test.py -vv -m '!^(ZEO|zope[.]app[.])' -t '!
checkResetCachesAPI' --all
Also see
Python 2.3 does not support the @decorator syntax.
Cheers,
Stefan
On 20. Mär 2007, at 10:05, Martijn Pieters wrote:
Log message for revision 73390:
- Backport a postonly decorator from Zope trunk's requestmethod
decorator factory.
- Protect various security-setting-mutators with this
This use-case is already covered by implementing
ZPublisher.Iterators.IStreamIterator. You can return a stream
iterator to Medusa and free the worker thread immediately.
Stefan
On 8. Mär 2007, at 05:40, Sidnei da Silva wrote:
Hopefully something similar could be done for files being sent
Care to share a test result?
FWIW, the nightlies basically do
svn co svn://svn.zope.org/repos/main/Zope/trunk Zope
cd Zope
./configure
make inplace
python2.4 test.py -q --all
Which leaves little room for errors, IMO ;-)
Stefan
On 8. Mär 2007, at 01:27, Christian Theune wrote:
I'm
Andreas,
The changes are not backward compatible, apparently.
http://mail.zope.org/pipermail/cmf-tests/2006-December/003656.html
http://mail.zope.org/pipermail/cmf-tests/2006-December/003657.html
Stefan
On 28. Dez 2006, at 14:58, Andreas Jung wrote:
I know that this migration is a big hammer
In fact, the Zope trunk is a bit of a mess as well.
http://mail.zope.org/pipermail/cmf-tests/2006-December/003658.html
Stefan
--
Anything that, in happening, causes itself to happen again,
happens again. --Douglas Adams
___
Zope-Dev maillist -
I haven't used lighttpd but the below rewrite rules doesn't specify
the port, it should.
Stefan
On 12. Okt 2006, at 19:33, yegor wrote:
url.rewrite-once = (
^/plone/(.*)$ =
/VirtualHostBase/http/rio.sci.ccny.cuny.edu/VirtualHostRoot/
_vh_plone/$1
)
--
Anything that happens, happens.
Yes, this is a blocker IMO as it breaks FTP for a whole class of
virtual hosting scenarios. No, I don't know how to fix, maybe Lennart?
Stefan
On 17. Sep 2006, at 12:52, Andreas Jung wrote:
--On 17. September 2006 12:38:11 +0200 Philipp von Weitershausen
[EMAIL PROTECTED] wrote:
AFAIK,
FileCacheManager does the copy-to-file-and-serve-as-iterator dance
for you.
http://www.dataflake.org/software/filecachemanager
Stefan
On 17. Sep 2006, at 21:09, Sidnei da Silva wrote:
One thing that is problematic today is serving large files
from the ZODB (ignoring the upcoming blob
These errors are *also* due to
ZODB.tests.testZODB.checkResetCachesAPI. The cache reset appears to
leave the Application object and/or transactions in a borked state.
All is well when I suppress checkResetCachesAPI:
$ python2.4 test.py -q -m '!^(ZEO|zope[.]app[.])' -t '!
Hi Lennart,
Philipp tells me you are responsible for the traversal integration.
Any ideas re http://www.zope.org/Collectors/Zope/2187?
Thanks,
Stefan
--
Anything that, in happening, causes something else to happen,
causes something else to happen. --Douglas Adams
, at 22:44, Stefan H. Holek wrote:
/me scratches head. I only see the error when I use the bot's
command line, a normal test run works fine.
$ python2.4 test.py -q --all
Running unit tests:
The following test left new threads behind:
testABOR (zope.server.ftp.tests.test_ftpserver.Tests)
New
/me scratches head. I only see the error when I use the bot's command
line, a normal test run works fine.
$ python2.4 test.py -q --all
Running unit tests:
The following test left new threads behind:
testABOR (zope.server.ftp.tests.test_ftpserver.Tests)
New thread(s): [_DummyThread(Dummy-36,
The Windows bot is borked, don't blame me ;-)
http://buildbot.zope.org/Zope%20branches%202.9%202.4%20Windows%
202000%20zc-bbwin2/builds/160/compile/0
Stefan
On 22. Aug 2006, at 12:47, [EMAIL PROTECTED] wrote:
The Buildbot has detected a failed build of Zope branches 2.9 2.4
Windows 2000
zope.pagetemplate.pagetemplatefile.PageTemplateFile reads an eventual
meta http-equiv=Content-Type ... header, or defaults to UTF-8.
Stefan
On 21. Jul 2006, at 16:53, Chris Withers wrote:
I wonder how Zope 3's filesystem-based ZPT's deal with this?
--
Anything that, in happening, causes
I use this to set debug-mode off:
# Switch off debug mode
import App.config
config = App.config.getConfiguration()
config.debug_mode = 0
App.config.setConfiguration(config)
Stefan
On 5. Jun 2006, at 11:50, Andreas Jung wrote:
Does anyone know how to write unittests that
You have to copy or symlink your Products directory into the ZEO
instance. At least those Products it tries to load for conflict
resolution.
HTH,
Stefan
On 2. Jun 2006, at 10:21, M. Krainer wrote:
How can I teach the zeo server to lookup my Products dir to resolve
the
conflict?
--
-1
The whole point of sticking with Zope2 is backward compatibility,
isn't it? If I wanted something that doesn't run my old products and
applications anymore I would go to Zope3 directly, why thank you.
Please keep this in mind in your spree to make Zope2 look like Zope3.
Backward
Note that Zope2.app() opens a new ZODB connection which you need to
close at some point. I suggest something along the lines of:
app = Zope2.app()
try:
products = app.Control_Panel.Products
...
finally:
app._p_jar.close()
http://www.zope.org/Members/4am/debugspinningzope
On 18. Apr 2006, at 16:45, Morten W. Petersen wrote:
Hi,
I have a problem with a Zope that hangs eating up 99.9% of the CPU.
I've tried to debug the problem by using DeadlockDebugger but that
doesn't even return when accessing it.
I guess the
[We seem to have lost Steve Alexander's test summarizer. I will
contact him in a separate mail.]
The switch to Python 2.3.4 caused tests for Zope 2.7 and 2.8 to
experience a funny problem with the logging module. Anybody want to
take a guess what's up here? I know these are not a truly
For the record: I am still opposed to this change. It basically
endows the request (as in self.REQUEST) with a getPhysicalPath
method, and I have no idea what kind of side-effects this may have.
AFAICS your test suite is the only suite around that wants to request-
wrap non-root objects.
On 4. Apr 2006, at 22:08, Paul Winkler wrote:
On Tue, Apr 04, 2006 at 08:09:05PM +0200, Stefan H. Holek wrote:
This looks fine to me because the world ends at parent. Your earlier
example wrapped an object that was in the middle of an acquisition
chain (IIRC),
no, I think you invented
Out of curiosity, you know that SimpleItem does not have a
constructor? You just inherit the one from ExtensionClass.Base, which
accepts everything and subsequently ignores it. So your item will
have an empty id. This *may* be what you want so your physical path
starts with '' instead of
On 4. Apr 2006, at 16:53, Paul Winkler wrote:
Hmmm, but unit tests very often don't reflect reality -
deliberately!
Because reality is Too Much Stuff.
True enough.
Any other opinions on this? Do we really need to require an App at
the root any time we want to acquire REQUEST? That seems
The one in ZopeTestCase.utils is also meant to play with startZServer
(same module). I agree that the one in Testing.makerequest could
probably gain ACTUAL_URL, and maybe even the request._steps hack to
make URL1 and friends available...
However, I have not seen these URL vars used
This is an old ZODB, right?
ZGlobals is used by ZClasses. There used to be a time when ZGlobals
was still a BTree when it should have been a BTrees.BTree. Then some
migration code was added. I suppose the error comes from the fact
that BTree.so is now finally no longer part of Zope and
I don't think makerequest is intended for wrapping anything but the
root application object. Putting the RequestContainer on arbitrary
objects doesn't feel right and certainly isn't how Zope does it, i.e.
you get a test fixture that doesn't reflect reality.
NotABug/WontFix ;-)
Stefan
On
+1
On 27. Mär 2006, at 07:35, Andreas Jung wrote:
Zope 2.8 ships/shipped with Five 1.0 which is very old and no longer
actively maintained. Most ppl doing currently development with Zope
2.8
are using Five 1.2. Should we upgrade the Five version in Zope 2.8
to Five 1.2 to make their lives
+1
I have handed systems with a thin ZClass layer on top to semi-
developers and they were *easily* able to take it from there. These
are people who would never have grokked (and bothered with) disk-
based Python development and all the mumbo-jumbo it entails.
No other system has anything
This turned out to be a bug in FSPythonScripts (no __file__ in script
globals). Fixed on all branches of CMF = 1.5.
Cheers,
Stefan
On 13. Feb 2006, at 16:48, Julien Anguenot wrote:
Florent Guillaume wrote:
Julien Anguenot wrote:
Tim Peters wrote:
[Julien Anguenot]
I'm having some
AFAIK the default configuration used by tests does not have a dbtab.
See lib/python/App/config.py.
Stefan
On Jan 14, 2006, at 16:45, Florent Guillaume wrote:
I'll look at it.
Florent
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This failure is tie up with Florent's
On 18. Dez 2005, at 17:58, Tim Peters wrote:
Nobody should be installing from a checkout to begin with, right?
Ok, so that's probably where we disagree then ;-)
I almost exclusively work with checkouts, and I would think many
developers (as opposed to users) do. Is there really no way to
make install does currently not work on 2.9 branch and trunk. I am
told that this is because zpkg cannot do it. I am also told that
the tarball would support make install, just not the checkout. I
never use tarballs, so I don't know for sure.
I'd very much like to see the canonical
Yup, that box is slowly dying on me. I will take down the nightlies
until I find a new machine to run them on.
Stefan
On 14. Dez 2005, at 15:35, Chris McDonough wrote:
FYI: These tests appear to be failing due to a race in the tests
they're exercising that could be exposed if the machine
import transaction
transaction.get()
transaction.commit()
transaction.abort()
transaction.savepoint()
This works since 2.8, but not in 2.7. Nearly every project has come
up with its own backward compatibility module though. See for example
CMFCore.utils.transaction or CMFPlone.transaction.
*Everything* you can do in the ZMI can be done from code. The ZMI is
not a magic entity, it uses the same APIs as everybody else. With
FSZSQLMethods you can stick max_rows: 0 into the lead-in comment, BTW.
Stefan
On 3. Nov 2005, at 03:37, Thanh Hải, Hà wrote:
My problem is I don't know
This change breaks Gadfly which doesn't seem to like 'null' at all. I
poked around in ZGadflyDA/gadfly a bit, but it's not obvious to me
how to fix the parser (*.mar files anyone?).
Stefan
[snip]
File /usr/local/Zope-2_8-branch/lib/python/Products/ZGadflyDA/
gadfly/kjParser.py, line
Since r37701 zopectl test forks off a child process [1]. On OSX I
now reliably get a traceback tacked onto the end of every test report:
Traceback (most recent call last):
File /Zope8/lib/python/Zope2/Startup/zopectl.py, line 312, in ?
main()
File
A TALES expression may be prohibitively expensive in any case, no
matter how simple it is kept. Please make sure to do some comparative
profiling. Cache keys are recomputed on every call of the script,
AFAICS. The thought of doing this in restricted Python makes my skin
crawl.
Stefan
This is due to how Python Scripts compute their cache keys. The
relevant snippet from PythonScript._exec() is:
asgns = self.getBindingAssignments()
name_context = asgns.getAssignedName('name_context', None)
if name_context:
keyset[name_context]
/lib/python/OFS/
Traversable.py, line 180, in unrestrictedTraverse
o = guarded_getattr(object, name, M)
AttributeError: manage_addFile
On 15. Feb 2005, at 21:29, Stefan H. Holek wrote:
Most excellent fix, thanks!
Stefan
On 14. Feb 2005, at 20:24, Jim Fulton wrote:
Tres Seaver wrote:
Jim and I
Most excellent fix, thanks!
Stefan
On 14. Feb 2005, at 20:24, Jim Fulton wrote:
Tres Seaver wrote:
Jim and I worked on an alternative fix today -- he will be checking it
in to your branch shortly, including modifying cAccessControl.
Done.
Jim
--
Software Engineering is Programming when you can't.
Tres,
I'd very much appreciate your opinion on
http://mail.zope.org/pipermail/zope-dev/2005-January/024237.html
http://mail.zope.org/pipermail/zope-dev/2005-January/024242.html
Plone is breaking left and right and I gotta do something about it...
Thanks,
Stefan
--
The time has come to start
The failing AccessControl tests can now be found on shh-aqtests-branch
in zope.org CVS.
Observations:
a) guarded_getattr checks object security of the acquiree if the
container denies access (at least that's my assessment).
b) The tests pass when either
- running Zope 2.7.3, or
-
The bug:
http://zope.org/Collectors/CMF/259
The fix:
http://mail.zope.org/pipermail/zope-checkins/2004-August/028152.html
This effectively changes how acquisition works in restricted Python. I
understand this may well be the point wink.
The consequences:
Zope sites experiencing seemingly random
I have restored test.py to the version shipping with Zope 2.7.3. The
changes made to accommodate Florent's use-case (adjacent symlinks)
broke some of mine. In particular, without calling realpath (or
abspath) on libdir, trailing slashes caused no tests to be found, as
did some combinations of
Seems docutils is not there just yet. I have added a test to
reStructuredText that tries to import the rst parser and it - gasp -
fails.
Stefan
--
The time has come to start talking about whether the emperor is as well
dressed as we are supposed to think he is. /Pete McBreen/
*sound of me protesting noisily*
Let me remind you of the Pope's decree:
http://mail.zope.org/pipermail/zope-dev/2004-November/024073.html
Stefan
On 16. Dez 2004, at 20:14, Andreas Jung wrote:
--On Donnerstag, 16. Dezember 2004 19:28 Uhr +0100 Christian Theune
[EMAIL PROTECTED] wrote:
Just for
Hm, I'd rather not raise exceptions.
getUserById was introduced in Zope 2.2 and since then has never raised
anything. From what I can see it is used as a kind of alias for
getUser, expected to return None if the user does not exist.
So, my intention is to make 'default' work, not to make it
In User.py the method is defined as
def getUserById(self, id, default=_marker):
try:
return self.getUser(id)
except:
if default is _marker: raise
return default
I am wondering whether anybody actually depends on the fact that
getUser is supposed to raise an
[docutils was moved from lib/python/docutils to
lib/python/third_party/docutils/docutils and an ugly sys.path hack
employed]
Why oh why do we always have to make it harder to start up Zope
(instead of making it simpler, for once)?
Extending the path in lib/python/sitecustomize only works if
Sorry Florent, I missed your warning mail.
I have two issues with the patch:
a) Trailing slash no longer works (--libdir Products/)
b) Some combinations of --libdir and --dir and symlinks no longer work
on Mac OS X (HFS)
Unfortunately os.getcwd() returns different paths in the presence of
This one does not even need symlinks (note that I run the tests from
Products):
localhost:/Users/zope/plone27/Products$ \
/Zope/bin/test.py -v -C ../etc/zope.conf --libdir . --dir CMFPlone
Running unit tests at level 1
Running unit tests from /Users/zope/plone27/Products/CMFPlone
Parsing
There is no bug, IMO. In CVS/SVN test.py lives in the root of Zope.
It just stays there when you make inplace or make instance (or make
anything for that matter). Removing it would break the checkout.
Stefan
On 18. Nov 2004, at 12:57, Lennart Regebro wrote:
Stefan H. Holek wrote:
+1 here too
Hi Tres!
On 22.10.2004, at 14:38, Tres Seaver wrote:
Given that the change was required to implement a security fix, and
without a reproducible test case for the reported breakage, I don't
think we can credit the rumors. We *definitely* don't want to defer
the security fix.
I still don't know
Note that 2.6.4 contains massive changes to the security
implementation. I'd imagine the product you use has not been updated
accordingly.
Stefan
On 13.10.2004, at 17:24, Nagarjuna G. wrote:
This product works perfectly till 2.6.3, starting from 2.6.4 and
upwards this problem appears. Looking
Note that I found it to be relevant which object I want to acquire
(don't ask me why, though).
E.g. going back to my CMFDefault examples, I *can* acquire
portal_workflow and portal_url, but I can *not* acquire
portal_membership and acl_users from a denied context. Go figure.
If I change the
While testing a large-ish customer project under Zope 2.7.3 we found
that
when an object with setDefaultAccess('deny') is used as the context for
a PythonScript, the script can no longer aquire tools from the portal
root.
Because a test says more than a thousand words, I added one to
On 09.10.2004, at 18:04, Tres Seaver wrote:
*By definition*, anybody who has declared 'setDefaultAccess('deny')
*wants* the behavior you describe: that declaration says, unless I
give you explicit permission for using a name, refuse.
If Plone has classes which make such assertions, then either
ZTUtils/__init__.py contains code like this:
if sys.modules.has_key('Zope'):
# import things
This is causing me repeated headaches when writing tests, because it
assumes/dictates a certain module import order. Can this go away,
please? I mean we know we are running Zope, don't we?
If
Did you try to recompile the PythonScripts?
Stefan
On Mittwoch, Jun 30, 2004, at 18:52 Europe/Vienna, Chris Withers wrote:
I upgraded a Zope 2.6.2 site to 2.7.1.
Since then, the history tab of all my old Script(Python)'s is broken.
--
The time has come to start talking about whether the emperor is
ZPublisher can only fill in arguments it knows about, i.e. that are
mentioned in the script's signature.
Stefan
On Sonntag, Jun 6, 2004, at 01:16 Europe/Vienna, Marshall Powers wrote:
So what is the deal?
--
The time has come to start talking about whether the emperor is as well
dressed as we
As BDBStorage has been removed from HEAD quite some time ago, I was
wondering whether it would be possible/advisable to remove it from 2.7
branch as well. Would it?
Stefan
--
The time has come to start talking about whether the emperor is as well
dressed as we are supposed to think he is.
I am under the impression that the ZOPE_CONFIG patch broke 2.7 branch.
Please see http://zope.org/Collectors/Zope/1233
Configuration is used very early, that's why I suggested to put the
logic into getConfiguration.
Zope tests fail for me, unfortunately Andreas cannot reproduce this.
Stefan
On
Me too! :(
Strangely, it worked fine earlier today...
Stefan
On Mittwoch, Apr 28, 2004, at 21:01 Europe/Vienna, Jim Fulton wrote:
Hm, I can get to it from a machine outside of ZC or Zope.org.
Is anyone else haveing troubles getting to it?
Jim
--
The time has come to start talking about
+0, not a problem. -1 for renaming 'Zope'.
I endorse the 'src/zope' idea.
Stefan
On Mittwoch, Apr 14, 2004, at 15:00 Europe/Vienna, Jim Fulton wrote:
Perhaps we can get more input on whether there's a problem.
A response with a positive sign (e.g. +1, +0, +2, ...) indicates
agreement that
I have made some small modifications to test.py to allow testing in
INSTANCE_HOMEs.
Please see: http://zope.org/Collectors/Zope/1279
An already patched version of test.py is available from here:
http://zope.org/Members/shh/TestRunner/test.py
Stefan
--
The time has come to start talking about
I believe I have found an elegant way to stop 'import Testing' from
changing the INSTANCE_HOME.
Please see: http://zope.org/Collectors/Zope/1260
Stefan
--
The time has come to start talking about whether the emperor is as well
dressed as we are supposed to think he is. /Pete
1 - 100 of 147 matches
Mail list logo
