[Zope] error: (10060, 'Operation timed out')
Hi, I am getting this error when using MailHost on my zope set up. I am using Zope 2.10.4-final, python 2.4.4, win32. Thanks for your help. Kamal Traceback (innermost last): Module ZPublisher.Publish, line 119, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 42, in call_object Module OFS.DTMLMethod, line 144, in __call__ DTMLMethod at /nation/index_html used for /nation/contact/sendPost URL: http://66.232.113.148:8015/nation/index_html/manage_main Physical Path:/nation/index_html Module DocumentTemplate.DT_String, line 476, in __call__ Module OFS.DTMLMethod, line 137, in __call__ DTMLMethod at /nation/table8 used for /nation/contact/sendPost URL: http://66.232.113.148:8015/nation/table8/manage_main Physical Path:/nation/table8 Module DocumentTemplate.DT_String, line 476, in __call__ Module OFS.DTMLMethod, line 137, in __call__ DTMLMethod at /nation/contact/sendPost/content_html URL: http://66.232.113.148:8015/nation/contact/sendPost/content_html/manage_main Physical Path:/nation/contact/sendPost/content_html Module DocumentTemplate.DT_String, line 476, in __call__ Module Products.MailHost.SendMailTag, line 116, in render Module Products.MailHost.MailHost, line 144, in send Module Products.MailHost.MailHost, line 161, in _send Module smtplib, line 244, in __init__ Module smtplib, line 310, in connect error: (10060, 'Operation timed out') ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] error: (10060, 'Operation timed out')
On Nov 12, 2007 3:27 PM, kamal hamzat [EMAIL PROTECTED] wrote: I am getting this error when using MailHost on my zope set up. I am using Zope 2.10.4-final, python 2.4.4, win32. Module smtplib, line 310, in connect error: (10060, 'Operation timed out') Verify that you can connect to the SMTP host from that machine. This is not a Zope problem but a connectivity problem; the smtblib module cannot connect to your SMTP server and times out instead. -- Martijn Pieters ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Tutorial Problems
I am a newbie to Zope and am evaluating it for a project but I am having a basic problem getting it to work properly. Any hints or advice would be helpful. I have searched online for similar problems to no avail. I have installed on a windows platform here are the specifics: Zope Version (Zope 2.10.5-final, python 2.4.4, win32) Python Version 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] System Platform win32 SOFTWARE_HOME C:\Zope\2.10.5\Zope\lib\python ZOPE_HOME C:\Zope\2.10.5\Zope INSTANCE_HOME C:\Zope\Instance\2.10.5 CLIENT_HOME C:\Zope\Instance\2.10.5\var Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) Although the ZMI works, I login with no errors, Products and/or Objects that should be accessed from a can URL can't : - i.e. Zoo Object Folder created per the Zope Book 2.6 ( http://localhost:8080/Zoo ) - I get the following error You have not created any users in this Zope instance. In order to log in and manage this Zope instance, you'll need to add an adminstrative user account. If you're running Zope on UNIX or Linux, you can create an administrative user account via the zopectl adduser command from a shell. *Note: You'll need to shut Zope itself down before zopectl adduser will work. Restart Zope after executing this command in order to log in.* If you're running Zope on Windows, you'll need to use the zpasswd.py utility in your Zope installation's bin directory at * C:\Zope\2.10.5\Zope\bin* to create a file named *inituser* in your Zope instance home at *C:\Zope\Instance\2.10.5* that contains the initial administrative username and password. - i.e. Silva ( http://localhost:8080/Zoo ) - loaded to the Products directory - Silva products show up in the products folder and I could find no errors in log files. Site Error An error was encountered while publishing this resource. *Resource not found* Sorry, the requested resource does not exist. Check the URL and try again. *Resource:* Silva GET - I also tried the Hello world tutorial on Zope3 and had the same result. Resource Not Found *Secondary Problem * b) The History Tab described in the Using the Zope Management Interface ( figure 3.8 ) does not exist ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope-dev] Duplicate directive registration allowed
I agree with your analysis. Could you file a bug report in launchpad? Bug now filed: https://bugs.launchpad.net/zope3/+bug/162166. \malthe ___ 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 http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 5 OK
Summary of messages to the zope-tests list. Period Sun Nov 11 13:00:00 2007 UTC to Mon Nov 12 13:00:00 2007 UTC. There were 5 messages: 5 from Zope Unit Tests. Tests passed OK --- Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Sun Nov 11 20:52:22 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008631.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Sun Nov 11 20:53:53 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008632.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Sun Nov 11 20:55:23 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008633.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Sun Nov 11 20:56:53 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008634.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Sun Nov 11 20:58:24 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-November/008635.html ___ 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 http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] why external version indexes don't fulfill all use cases for development
Hey, On Nov 11, 2007 10:34 PM, Jim Fulton [EMAIL PROTECTED] wrote: On Nov 11, 2007, at 2:06 AM, Martijn Faassen wrote: [snip] This breaks a fundamental assumption for releases. When I release something, I expect it to work tomorrow, next month, and next year. If you want this, then you can't rely on the KGS. When releasing our applications, we don't rely on a KGS. We fix all of the versions we're using. IMO, the KGS shouldn't try to solve this problem. A KGS should be helpful for developers and development frameworks. A KGS will be more useful if the quality remains high. A KGS is similar to a traditional monolithic release. After all, bug fix Zope releases have been known to break applications too. I got completely confused by your answers you gave previously: you were talking about feature releases, but of what? Basically here you say that KGS replaces a monolithic release of Zope 3. I see KGS as useful for the developers of Zope 3 classic. I see KGS as a useful source of tested lists of versions where they are related to Zope 3. With code, we know that history, and branches, and so on, are important. We use Subversion. With KGS we only have an ongoing trunk. I'm not sure why you keep saying trunk. I'm not sure if you are being imprecise, or if I'm missing something. There's no reason a KGS couldn't be managed with a revision control system. That might be a very good idea. I say this as this is the impression I get from it. Saying that a KGS could be managed with a revision control system is nice, but can it now? How complicated would that make it? Does it make sense to maintain this information externally to the packages? [snip] There are some fundamental problems with external lists or indexes: * we need to know about the dependency of dependencies, even if we never use them directly. Information hiding is broken. I'm not sure how this is a problem with version lists (external or otherwise) or indexes. Dependencies of dependencies itself isn't a problem, as this information is still in packages themselves. The versions of dependencies isn't, and this is a problem, because I don't *want* to know about dependencies of dependencies, or their versions. I don't want to have to care. The packages themselves should know this. The story for beginners wouldn't be good enough, as they'd need to know too. With ZCML we're finally resolving this by putting this dependency structure in ZCML. Not ideal, but at least when you include package X which needs Y which needs Z, you don't need to manually include the ZCML of Y and Z anymore. Now with package dependencies and versioning, I need to make decisions on the versions of Y and Z, while I just care about using X. I don't want to know this stuff. A beginner can of course, if he's lucky, interact with an index like KGS that makes decisions for them. That works until they need a different version or different package than what is maintained in the index. In that case, they don't want anything external to make the decisions. The basic thing I'd like is to just to ask the package: give me the versions *you* think you can work with. If I'm tracking this package in subversion or upgrade to a new release of the package, this list of best versions might change, too. I don't want to have to know, just like I don't want to have to know about the implementation details of a package. Dependencies and the versions of such are an implementation detail. One I might on occasion like to override, just like I sometimes need to override the implementation details of a class by subclassing, but that should be further along the curve, not immediate. I think it would be reasonable for packages higher up in the dependency tree to have the ability to override version decisions made by packages lower down (as long as there aren't any conflicts within the structure). In these case these package explicitly decide to take over responsibility. * a single list will never do it. We intend to have many different applications that may depend on different versions of packages. Grok may need a newer zope.publication than your application does. A Grok extension may need an even newer version than Grok does. We'll be baking endless amounts of lists this way. I think each application will need to come up with a version list for each of it's releases. In development, an application can use an index or external version list as a starting point. For example, I see a KGS being useful as a (fairly) stable baseline for development. When an application is ready for release, it should fix it's versions. I've tried to make this easy to do with buildout. When you're preparing to make a release, run buildout in verbose mode (-v) It will print out the versions it picked in a format that is easily turned into a version list. Sure, I know about all this. I just am saying that this doesn't do enough. During development I decide I want to
Re: [Zope-dev] why external version indexes don't fulfill all use cases for development
Hey, On Nov 12, 2007 12:02 AM, Stephan Richter [EMAIL PROTECTED] wrote: [snip] Like Linux distributions, there will be a KGS for every Zope 3 release. I have already requested a new directory called zope-dev where new feature releases can be tested. Okay, I didn't understand that KGS is replacing the monolithic release story for Zope 3. That's fine as far as it goes. I was focused on the ability that eggs give us for packages to move at different speeds of evolution, and the desire to pick those eggs that we prefer in our applications. If you don't need that, then KGS is basically Zope 3 release + a few features. [snip] We intend to let packages move at different feature-release speeds, and we can't have a KGS for each package. You do not need to have a single KGS for every package. But believing that we can just randomly make new feature releases that work with the rest of the world is naive at best. We have seen already what happens, if everyone uses their own set of versions and packages. Clearly things didn't work in the past. You can't just throw random versions of eggs together. We couldn't do anything better, as the information about what worked together was missing. KGS adds that information back, and that's great. But the information is external to the actual packages. This has drawbacks. I'm saying that if we add this information in the packages internally, we'll be better off, as historical versions and future versions can work. The reuse story is improved. You can make your own selection of versions and have a decent chance it will work together. A development KGS will be used to test new feature releases. What KGS doesn't have is history. Yes, it does. Why do you think I manage the controlled-packages.cfg file in SVN? And in SVN, I do not create branches and tags without a reason. Okay, that's a history. It's a history external to the packages, while the packages have their own history. It's also a global history, while packages can evolve independently. Development decisions of a package's development can change dependency information. It therefore seems natural to me that this information is maintained next to the package. If it's not, and zope.component starts to rely on a newer version of zope.interface, I'd need to maintain this centrally with KGS. We introduce a new monolithic structure where we just removed it. We add back explicitly what was there implicitly: an SVN trunk of Zope 3 maintaining versions that all work together. That's fine to retain the features Zope 3 development had, but I thought the point of splitting Zope 3 up was to be able to forget about the SVN trunk of Zope 3 and just worry about what's right for zope.component. [snip] With Grok, we use an external versions list. We can use this to solve the above problem. We basically take snapshots of what is in KGS. This allows us to maintain some history, though it isn't ideal either, as it's quite a bit of overhead. How is this overhead? Besides releasing Grok, we also need to maintain snapshots of what is in KGS, make such changes as are needed, and publish them. Previously we just released new versions of Grok. That's increased maintenance and release overhead I'd like to get rid of again. If I build an application or framework on top of Grok, I will need to maintain yet another external list for the extra packages of this application, fixing those versions. Why? I don't follow that? Because these packages may be of different versions that in KGS, or may not be managed by KGS altogether. So, while annoying, that is somewhat manageable. Now imagine I want to use a completely separate Python library with my Grok application. This python library has dependencies itself again. This means I will need to know about versions of those dependencies as well, and fix them into my application's list. Yes. I see this as an advantage. Version specifications in `setup.py` usually contain ranges of allowed versions. What happens if one release in the range does not work? Then you make false promises. The only way to avoid this would be by specifying all allowed versions exactly, which makes no sense. That's true. Where I'd like to specify this is as near as possible to where I make the decision to fix these versions. In case of an application, that may be the application. Often that's not the case though: in the case of a library that uses these packages, I'd like it to be the library, and in case of a framework, I'd like it to be the framework. When I develop an application at most I'd like to get the warning: these packages still don't have fixed versions. I'd prefer that list to be empty. There are some fundamental problems with external lists or indexes: * we need to know about the dependency of dependencies, even if we never use them directly. Information hiding is broken. This is a requirement not a problem statement. I don't understand Information hiding
[Zope-dev] Trying to summarize the requirements for the package version story
I'm trying to get my head around the package versioning requirements. It seems to me that we have the following requirements: 1. We need to be able to in a buildout say I want to use Zope version 3.4, thanks, and the buildout should then download the latest versions of the relevant Zope packages that make up Zope 3.4. 1a. If bugfixes are released bin/buildout will install and upgrade the bugfixes. 1b. If a version of zope.something is released that is NOT compatible with 3.4, but compatible with 3.5, that version will NOT be downloaded. 2. We need to be able to in a buildout say I want to use Zope version 3.4.5, thanks, and the buildout should then download that the set of eggs that is Version 3.4.5. 2a. If bugfixes are released for Zope 3.4 these will NOT be downloaded. (2b. Although if there is a way to make security fixes to be automatically downloaded, that would be neat) 3. We need to be able to in a buildout say I want to use Grok 1.2 and Grok 1.2 will automatically depend on a specific version of Zope, say 3.4.5. I.e., we want to be able to extend Known Good Sets. 4. We want to in the buildout be able to specifically override a version of a package, I say that we want to use zope.whatever 3.5.6, although it is not an approved part of the Zope version we have specified. 5. We want an egg that the buildout depends on to be able to override the version of a package. I.e, if the buildout installs. zc.coolpackage, and that requires zope.something 1.3.2, although the Zope 3.4 KGS specifies 1.2.3, 1.2.3 should be used. 1 can not be solved by having version information in the packages, because I think the list of versions, AKA the Known Good Set is going to have to be updated more or less manually with releases, right? Because you can't just take the last version of everything, because sooner or later somebody releases somthing that breaks it. And updating the list would require you to re-release a package, which is bad. 2a can be solved by version information in packages, 2b can not. 3 needs an extension mechanism. 4 and 5 are version conflict resolution problems, which already exists, right? ___ 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 http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] why external version indexes don't fulfill all use cases for development
On Nov 11, 2007, at 6:34 PM, Stephan Richter wrote: On Sunday 11 November 2007, Jim Fulton wrote: This breaks a fundamental assumption for releases. When I release something, I expect it to work tomorrow, next month, and next year. If you want this, then you can't rely on the KGS. When releasing our applications, we don't rely on a KGS. We fix all of the versions we're using. IMO, the KGS shouldn't try to solve this problem. A KGS should be helpful for developers and development frameworks. A KGS will be more useful if the quality remains high. A KGS is similar to a traditional monolithic release. After all, bug fix Zope releases have been known to break applications too. I really hope you will use the KGS as a starting point somewhen for your internal applications as well. :-) (Note that you can now override versions using the new extends feature that I shamelessly copied from buildout.) And I am not saying this to promote the KGS. I have a concrete example. Probably as part of a project, Benji did some development on zope.testbrowser. He fixed the versions of all dependencies in buildout.cfg. However, those versions were a version sub-graph of a ZC internal dependency graph that I do not have access to. It was also already pretty outdated referring to dev and alpha releases. So while testbrowser might be working with those dependency versions, it might still be broken for me, because I have a totally different dependency graph. The worst scenario, which luckily has not happened yet, is that we fix things back and forth because of different dependency graphs. I thus propose that all packages in svn.zope.org should use a KGS for testing, because it is a fully public dependency graph. I am not sure whether it should be the latest stable KGS or the development KGS or whatever. Time will provide an answer. I think you make a good point. +1 on using *some* KGS. Jim -- Jim Fulton Zope Corporation ___ 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 http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] why external version indexes don't fulfill all use cases for development
On Monday 12 November 2007, Jim Fulton wrote: I thus propose that all packages in svn.zope.org should use a KGS for testing, because it is a fully public dependency graph. I am not sure whether it should be the latest stable KGS or the development KGS or whatever. Time will provide an answer. I think you make a good point. +1 on using *some* KGS. Since we only have the Zope 3.4 KGS now, I think it would be the best one to use now. :-) The easiest way to do this is to add the following line to the buildout section of the package's `buildout.cfg` file: index = http://download.zope.org/zope3.4 (I know you know that Jim; it is for the benefit of people reading this mail. ;-) Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ 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 http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Hivurt code hosting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Winkler wrote: On Sun, Nov 11, 2007 at 06:37:22PM -0500, Stephan Richter wrote: Yes, everyone has to sign a contributor agreement, but you do not have to become a Zope Foundation member. I had the impression, from the recent ZF IRC chat, that the process of adding new contributors is currently blocked - but perhaps I misunderstood? We can't move the code ownership yet (from ZC to ZF) because once we *do*, becoming a contributor will be governed by ZF rules, which are currently self-contradictory: at that point, we would be unable to add new committers at all. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHOIsY+gerLs4ltQ4RAi2yAJ40m2B5ybP+5JklsjfnRJc3ou4t4wCgvXWp bpfceBN6LIelVJIEDqzGcmk= =0jE+ -END PGP SIGNATURE- ___ 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 http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Hivurt code hosting
On Mon, Nov 12, 2007 at 12:19:20PM -0500, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Winkler wrote: On Sun, Nov 11, 2007 at 06:37:22PM -0500, Stephan Richter wrote: Yes, everyone has to sign a contributor agreement, but you do not have to become a Zope Foundation member. I had the impression, from the recent ZF IRC chat, that the process of adding new contributors is currently blocked - but perhaps I misunderstood? We can't move the code ownership yet (from ZC to ZF) because once we *do*, becoming a contributor will be governed by ZF rules, which are currently self-contradictory: at that point, we would be unable to add new committers at all. I see, thanks. What I just can't figure out is: what is the current process of becoming a comitter. http://www.zope.org/DevHome/Subversion/FrontPage still links to http://www.zope.org/DevHome/Subversion/Contributor.pdf which is very old. Is it still used? I probably still have commit access from the pre-ZF days, but the employer information I submitted has changed several times since then. Now that I've started working for a more enlightened employer, I would like to start checking in bugfixes again but I don't know whether I should just use my old keys, or submit a new form, or what. - PW ___ 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 http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Hivurt code hosting
On Monday 12 November 2007, Paul Winkler wrote: I probably still have commit access from the pre-ZF days, but the employer information I submitted has changed several times since then. Now that I've started working for a more enlightened employer, I would like to start checking in bugfixes again but I don't know whether I should just use my old keys, or submit a new form, or what. You can use your old keys, if you have them. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ 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 http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] why external version indexes don't fulfill all use cases for development
Stephan Richter wrote: The easiest way to do this is to add the following line to the buildout section of the package's `buildout.cfg` file: index = http://download.zope.org/zope3.4 (I know you know that Jim; it is for the benefit of people reading this mail. ;-) I've been trying to follow this whole thread but it's been pretty high volume so apologies if I've missed something... If I specify index as above, how do I get other packages which may not appear in that index? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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 http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Hivurt code hosting
On Nov 12, 2007, at 2:00 PM, Paul Winkler wrote: On Mon, Nov 12, 2007 at 12:19:20PM -0500, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Winkler wrote: On Sun, Nov 11, 2007 at 06:37:22PM -0500, Stephan Richter wrote: Yes, everyone has to sign a contributor agreement, but you do not have to become a Zope Foundation member. I had the impression, from the recent ZF IRC chat, that the process of adding new contributors is currently blocked - but perhaps I misunderstood? We can't move the code ownership yet (from ZC to ZF) because once we *do*, becoming a contributor will be governed by ZF rules, which are currently self-contradictory: at that point, we would be unable to add new committers at all. I see, thanks. What I just can't figure out is: what is the current process of becoming a comitter. http://www.zope.org/DevHome/Subversion/FrontPage still links to http://www.zope.org/DevHome/Subversion/Contributor.pdf which is very old. Is it still used? Yes. I probably still have commit access from the pre-ZF days, but the employer information I submitted has changed several times since then. Now that I've started working for a more enlightened employer, I would like to start checking in bugfixes again but I don't know whether I should just use my old keys, or submit a new form, or what. Submitting a new form would be nice. :) Jim -- Jim Fulton Zope Corporation ___ 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 http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: why external version indexes don't fulfill all use cases for development
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: Stephan Richter wrote: The easiest way to do this is to add the following line to the buildout section of the package's `buildout.cfg` file: index = http://download.zope.org/zope3.4 (I know you know that Jim; it is for the benefit of people reading this mail. ;-) I've been trying to follow this whole thread but it's been pretty high volume so apologies if I've missed something... If I specify index as above, how do I get other packages which may not appear in that index? You install them in a separate transaction: the 'index_url' setting in a pacakge setup.py only governs where setuptools goes to find packages which are dependencies of that package. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHONmM+gerLs4ltQ4RAoGwAJ4lTOkIgbQxtexoXx+4MEB638ShigCfVx7z XnneNgqnqZ7x65ph1HXuaVI= =O713 -END PGP SIGNATURE- ___ 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 http://mail.zope.org/mailman/listinfo/zope )
[Zope-PAS] eggified PAS
I noticed that Tres eggified PluggableAuthService. Unfortunately the old location still exists and changes where made there. Is there any reason not to merge those into products.PluggableAuthService and remove trunk and the 1.5 branch at the old location? Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas
[Zope-DB] Seeking help with Accessing Zope from PostgreSQL
I'm trying to implement the scheme for Accessing Zope from PostgreSQL that is described in http://zope.org/Members/pupq/zope_in_pg. I'm trying to implement it in a Plone installation in a WinXP environment (Plone 2.5.2, Zope 2.9.6, Python 2.4.3, win32, PostgreSQL 8.1.10). I have changed the file paths in the above reference's zstart() function so that they refer to the appropriate (I hope) directories and files in my environment. My zstart() now reads like this: CREATE or REPLACE FUNCTION public.zstart() RETURNS pg_catalog.text AS ' if GD.has_key(zope_app): GD[app]._p_jar.sync() return import sys sys.path.insert(0, \Program Files\Plone 2\Zope\lib\python) sys.path.insert(0, \Program Files\Plone 2\Zope\lib\python\Products) import Zope sys.argv=[zope] Zope.configure(\Program Files\Plone 2\Zope\skel\etc\zope.conf.in) GD[zope_app]=Zope.app() from ZODB.Transaction import get_transaction GD[zope_get_trans]=get_transaction ' LANGUAGE 'plpythonu' VOLATILE; But when I try to run zstart() with this SQL: select zstart(); I get this error: PostgreSQL Error Code: (1) ERROR: plpython: function zstart failed DETAIL: exceptions.SystemExit: 2 0 Record(s) Returned Any suggestions to make this work? ~ TIA ~ Ken ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
