Re: [Zope-dev] Zope RPMs/debs and Linux FHS
On Mon, 2002-10-14 at 03:14, Dirk Datzert wrote: > Chris, > > please use always a buildroot ! You can set an option > in the compile-all script that tell python to set the real realase path in the > tracebacks. This is true, but the branch no longer uses compileall. Instead, distutils does the work. I suppose we could fall back onto compileall. Thanks, - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope RPMs/debs and Linux FHS
> > > *) Byte compiling: Why not schedule an 'at' job to do the byte compile? > > The only reason I care about when the files are compiled is that if the > files are byte-compiled in the rpm build root, tracebacks will contain > references to the buildroot in the python filenames. I could do it in > postinstallation, but then I'd need to clean up the py[co] files > manually during uninstall which seems a little icky. > > I suppose for "real" releases we could just not use a buildroot, but > this is not too convenient. > Chris, please use always a buildroot ! You can set an option in the compile-all script that tell python to set the real realase path in the tracebacks. Regards, Dirk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How can I find out who visited a URL within my ZopeProduct?
Steve Alexander wrote: >> My application can then automatically send notifications to others >> based on the execution of the VisitURL Command. >> I can send email to my group saying "So and so has seen the contract" > > Incorrect. > > This shows that they read the original email, and intended to view the > contract at the URL. However, after that point, we only know that Zope > attempted to send the page at the URL back to the browser. You have no > proof that such data was ever received by the browser in any way > meaningful to the end-user. This gets even more complicated when http > proxies are involved. You are right, of course, but I believe that, for our purposes, this is a distinction without a difference. The notification is purely for administrative purposes-- just a convenient reminder to our client if their invoice has not been paid yet. If *their* client denies that they have seen the invoice, we don't have a legal basis for non-repudiation, but as it turns out, this is a pretty rare problem in practice. I suppose the only way to legally guarantee that someone has seen something delivered as a web page is for them to attach their digital signature to the form and submit it back to the server. Ultimately we will probably have to do this, but for now the VisitURL notification is enough... --Craeg ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: ofpa
Title: fkneygkdwobtisaxxraendtvdidgcnyjxmnytxfqp MP3SA En Ýyi En Büyük Arþiv Türkçe MP3 Yabancý MP3 Türkçe Albümler Yabancý Albümler Pop Müzik Arabesk Müzik Rock Müzik Latin Müzik Hip-Hop Müzik Türk Sanat Müziði Türkü Arþivi Film Müzikleri Müzik konusunda aradýðýz her çeþidi bulabileceðiniz bir site artýk var. Her gün güncellenen ve istekleriniz doðrultusunda yeni eklemeler yapýlan sitemizde kaliteyi fark edeceðinize eminiz. http://www.mp3sa.com f^ ëæj)eËY¢züè¥ê+m§ÿåËlÎ^¢¸?¨¥©ÿ+-wèÿ:)yׯ6+¢Ë)¢Ël¢±Ó0·§rb^«^vX¬¶Èm¶ÿ+-³:)zàþf¢f§þX¬¶)ߣüè¥æ§§qèm¶ÿ+-³:)zàþf¢f§þX¬¶)ߣüè¥
Re: [Zope-dev] Idea: Awaking Zope to Life
Ulrich, You may also be interested in http://cvs.zope.org/Products/Scheduler/ (it has a dependency on http://cvs.zope.org/Products/Event/ and a Zope >= than 2.6b1). It relies on an external "clock" process to tickle it every so often, but you could of course kick off a Zope thread to do this... - C On Sun, 2002-10-13 at 11:44, Ulrich Eck wrote: > Hi there, > > I just had an Idea and want to hear your comments on the following: > > Zope is a Request-Based System. It has no internal scheduling functions > except one installs Xron. > > I have written a MicroThread Scheduler using python2.2 generators > that supply cooperative Multithreading. > > Now the point: > > I want to integrate this Scheduler as one Thread (like Xron) > to Zope as "Service" where clients could register a callback > with parameters which are called regularly with a certain priority. > > Zope's Persistent Object Database would morph to an completely > persistent Program that handles requests too. > > One could use it to implement better Workflow capabilities, > or an Event Sytem (a client would register a Thread that > checks for incoming messages and handles them). Many more things > could be done .. > > What are the pitfalls i can run into, when trying to implement this ?? > I could think of concurrency issues, problem with threads, context, > security .. any concrete hints ?? > > What do you think about that ?? > > > Ulrich Eck > > net-labs Systemhaus GmbH > Ebersberger Str. 46 > 85570 Markt Schwaben > fon: +49-8121-4747-11 > fax: +49-8121-4747-77 > email: [EMAIL PROTECTED] > http://www.net-labs.de > > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope RPMs/debs and Linux FHS
On Sun, 2002-10-13 at 12:15, Adam Manock wrote:
> I was planning to start from scratch with building a RPM for 2.6
> that would work on at least RedHat 8.x AND 7.x.. Coincidentally,
> this is something I planned to start on tomorrow! :-)
Oh happy coincidences! ;-)
FWIW, in order for my spec file to make any sense in the context of
Zope, you'll need to check out the 'chrism-install-branch' of Zope via:
cvs -d :pserver:cvs.zope.org:/cvs-repository -d ChrisMInstallBranch -r
chrism-install-branch Zope
Then:
cd ChrisMInstallBranch
./configure
make rpmdist
Note that the current spec file claims that Python >= 2.2.1 is required
to install the rpm. This is only because the RedHat-shipped 2.2.0
doesn't include the compiler package, required for Zope to run
properly. It should also work with 2.1.3, but RedHat doesn't have any
2.1.X RPMs. :-( To make matters worse, Python 2.2.1 has a few bugs that
are known to cause Zope to crash, so the spec file should really depend
on either "== 2.1.3" or "== 2.2.2".
In any case, if you've got patches, send them my way!
I am hoping that the chrism-install-branch will become the basis for the
configuration and packaging machinery for Zope 2.7. It supports a
"configure; make; make install" install process for source distros that
is easy to adapt for binary distros.
> Instead, I'll take a few hours tomorrow to test your spec on
> RedHat 8.0, it would be *really* good if this could be the basis
> of and future 2.6 / 2.7 packaging efforts...
2.6 doesn't (and likely wont) have the machinery for it, but 2.7
should. It'd be very cool to be ahead of the game for 2.7 as far as
packaging and distribution goes...
> Zope, Zope-zserver and Zope-PCGI packages seem like a good idea.
> Most RPM dists seem to have at least a "-server" sub package if they
> provide a daemon (eg postgresql). Init scripts, the "data" dir, etc
> all go in the "-server" subcomponent
In my mind, Zope doesn't really have a client subcomponent (Zserver
really is part of Zope proper), but it might be nice to break out
PCGI/FCGI support.
> AFAIK on RedHat /opt or "mixed in" (/usr/bin etc) is fine, the argument
> goes "if RPM tracks all the files for you, why use /usr/local or /opt?"
> /opt is used too, the only problem being that it isn't often created
> separate from the "/" partition, so there often isn't alot of space
> there!
Darn. That's true.
The FHS says that opt is a viable place for this kind of thing (whereas
/usr maybe isnt).. The resulting /opt directory structure is also only
about 26MB, as well so maybe it's OK?
> One "trick" to note is for creating the inituser (from 2.5.1):
>
> # Declare the Superuser of the Default Zope Project
> rm $RPM_BUILD_ROOT/usr/share/zope/inituser
> %{PYTHONAPP} $RPM_BUILD_ROOT/usr/bin/zpasswd -u admin -p 123
> $RPM_BUILD_ROOT/var/zope/inituser
> chmod 0640 $RPM_BUILD_ROOT/var/zope/inituser
Yeah, thanks... I'd rather not ship a default password because as soon
as we do, there's bugtraq and security people crawling all over the
place yelling at us. I added a "write_inituser" command to the zctl
front-end for this purpose, so folks will need to use it before they can
log in to Zope. It would be nice if RPM installers offered ubiquitous
interactivity the way that Debian's does, but alas.
- C
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope RPMs/debs and Linux FHS
On Sun, 2002-10-13 at 10:54, Federico Di Gregorio wrote: > > - Jeff's puts pid files into /var/run, while mine creates pid files > > directly in INSTANCE_HOME/var. > > perfect. please do that for debian packages too and let /usr for > official debian packages of Zope. Do you mean I should use /usr or I should not? I see that Gregor's package uses /usr/lib/zope to store the software home files... I'm not sure what this means to the FHS. I also see that the existing debian Zope product packages (at least the ones I've looked at) put their products into /usr/lib/zope/Products. > you can install only what you really need. for example debian as one > package for every Product not included in base Zope, so, if i want the > CMF i have only to do: > > apt-get install zope-cmfdefault Right.. this is very cool. Luckily, I'm only worrying about Zope itself at the moment... Product packagings are a different story. > > - anybody has any opinions of where Zope files distributed via RPMs and > > debs should really go, especially wrt to the Linux FHS. I'm not sure > > there is a right answer, but I don't know beans about this, so I > > figure I'll ask. A file named 'Zope.spec.in' is attached to this > > email which is the input file to create a Zope RPM spec file during > > the make process, to give a better idea of how this works. > > /opt and /var/opt is the right place. zope.org is a "software vendor" > and stuff from software vendors should gointo /opt. OK, I think so too... I'd like to hear the opinions of the existing debian and rpm maintainers as well, though... A tremendous amount of effort has been put into packaging Debian and RPM Zope packages. I want to make sure that what I do doesn't step on anybody's toes in this realm... it will be problematic if we start to create rpm and deb distros that are completely different than the ones that already exist. At the same time, it would be nice if we could come up with some sort of cross-platform standard for file locations. - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope RPMs/debs and Linux FHS
On Sun, 2002-10-13 at 10:31, Adrian Hungate wrote:
> This looks GREAT!!
Thanks a lot..
> A couple of points:
> *) Python 2.2.x ?? This is scheduled for Zope 3 ?? Is there any way this
> could find its way in to a 2.x release?
I believe Zope 2.7 will require Python 2.2.X. It's my hope to merge
this into the Zope trunk at some point in the near future (which will in
turn become Zope 2.7 at some point).
> *) Byte compiling: Why not schedule an 'at' job to do the byte compile?
The only reason I care about when the files are compiled is that if the
files are byte-compiled in the rpm build root, tracebacks will contain
references to the buildroot in the python filenames. I could do it in
postinstallation, but then I'd need to clean up the py[co] files
manually during uninstall which seems a little icky.
I suppose for "real" releases we could just not use a buildroot, but
this is not too convenient.
> *) Ownership/perms on the 'var' dir, this will need to be the same as the
> user Zope runs as, which I assume is not the same as ${zopeuser}
Well, I had thought for default installs, the %{zopeuser} will be "zope"
and this user will indeed be both the owner of the var dir and the owner
of the process. Do you think there is a better way?
> Minor personal request:
> *) Is there any way to detect if apache is installed, and have zope run as
> the apache user? This would be great for CGI support, etc.
What user does apache run as? "apache"?
Thanks!
- C
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope RPMs/debs and Linux FHS
Looks good,
I was planning to start from scratch with building a RPM for 2.6
that would work on at least RedHat 8.x AND 7.x.. Coincidentally,
this is something I planned to start on tomorrow! :-)
Instead, I'll take a few hours tomorrow to test your spec on
RedHat 8.0, it would be *really* good if this could be the basis
of and future 2.6 / 2.7 packaging efforts...
> - anybody has opinions on the packaging layout. Why is it advantageous
> to have many packages rather than one?
Zope, Zope-zserver and Zope-PCGI packages seem like a good idea.
Most RPM dists seem to have at least a "-server" sub package if they
provide a daemon (eg postgresql). Init scripts, the "data" dir, etc
all go in the "-server" subcomponent
[adam@blackbox adam]$ rpm -qa | grep postgresql
postgresql-7.2.2-1
postgresql-server-7.2.2-1
postgresql-libs-7.2.2-1
[adam@blackbox adam]$ rpm -ql postgresql-server
/etc/rc.d/init.d/postgresql
/usr/bin/initdb
/usr/bin/initlocation
/usr/bin/ipcclean
/usr/bin/pg_ctl
/usr/bin/pg_passwd
/usr/bin/postgres
/usr/bin/postmaster
/usr/lib/pgsql
/usr/lib/pgsql/backup
/usr/lib/pgsql/backup/pg_dumpall_new
/usr/lib/pgsql/plpgsql.so
/usr/share/locale/cs/LC_MESSAGES/postgres.mo
/usr/share/locale/de/LC_MESSAGES/postgres.mo
/usr/share/locale/hu/LC_MESSAGES/postgres.mo
/usr/share/locale/ru/LC_MESSAGES/postgres.mo
/usr/share/locale/zh_CN/LC_MESSAGES/postgres.mo
/usr/share/locale/zh_TW/LC_MESSAGES/postgres.mo
/usr/share/man/man1/initdb.1.gz
/usr/share/man/man1/initlocation.1.gz
/usr/share/man/man1/ipcclean.1.gz
/usr/share/man/man1/pg_ctl.1.gz
/usr/share/man/man1/pg_passwd.1.gz
/usr/share/man/man1/postgres.1.gz
/usr/share/man/man1/postmaster.1.gz
/usr/share/pgsql
/usr/share/pgsql/pg_hba.conf.sample
/usr/share/pgsql/pg_ident.conf.sample
/usr/share/pgsql/postgres.bki
/usr/share/pgsql/postgres.description
/usr/share/pgsql/postgresql.conf.sample
/var/lib/pgsql
/var/lib/pgsql/.bash_profile
/var/lib/pgsql/backups
/var/lib/pgsql/data
> - anybody has any opinions of where Zope files distributed via RPMs and
> debs should really go, especially wrt to the Linux FHS. I'm not sure
> there is a right answer, but I don't know beans about this, so I
> figure I'll ask. A file named 'Zope.spec.in' is attached to this
> email which is the input file to create a Zope RPM spec file during
> the make process, to give a better idea of how this works.
AFAIK on RedHat /opt or "mixed in" (/usr/bin etc) is fine, the argument
goes "if RPM tracks all the files for you, why use /usr/local or /opt?"
/opt is used too, the only problem being that it isn't often created
separate from the "/" partition, so there often isn't alot of space
there!
One "trick" to note is for creating the inituser (from 2.5.1):
# Declare the Superuser of the Default Zope Project
rm $RPM_BUILD_ROOT/usr/share/zope/inituser
%{PYTHONAPP} $RPM_BUILD_ROOT/usr/bin/zpasswd -u admin -p 123
$RPM_BUILD_ROOT/var/zope/inituser
chmod 0640 $RPM_BUILD_ROOT/var/zope/inituser
Adam
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Idea: Awaking Zope to Life
On Sunday 13 October 2002 17:44, Ulrich Eck wrote: > Hi there, > > I just had an Idea and want to hear your comments on the following: > > Zope is a Request-Based System. It has no internal scheduling functions > except one installs Xron. > > I have written a MicroThread Scheduler using python2.2 generators > that supply cooperative Multithreading. > > Now the point: > > I want to integrate this Scheduler as one Thread (like Xron) > to Zope as "Service" where clients could register a callback > with parameters which are called regularly with a certain priority. > > Zope's Persistent Object Database would morph to an completely > persistent Program that handles requests too. > > One could use it to implement better Workflow capabilities, > or an Event Sytem (a client would register a Thread that > checks for incoming messages and handles them). Many more things > could be done .. I really need something like that for OpenFlow. > What are the pitfalls i can run into, when trying to implement this ?? > I could think of concurrency issues, problem with threads, context, > security .. any concrete hints ?? No, but we can explore that together. > What do you think about that ?? Really interesting, I`m interested in helping you for that. Bye, Vincenzo. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Idea: Awaking Zope to Life
Hi there, I just had an Idea and want to hear your comments on the following: Zope is a Request-Based System. It has no internal scheduling functions except one installs Xron. I have written a MicroThread Scheduler using python2.2 generators that supply cooperative Multithreading. Now the point: I want to integrate this Scheduler as one Thread (like Xron) to Zope as "Service" where clients could register a callback with parameters which are called regularly with a certain priority. Zope's Persistent Object Database would morph to an completely persistent Program that handles requests too. One could use it to implement better Workflow capabilities, or an Event Sytem (a client would register a Thread that checks for incoming messages and handles them). Many more things could be done .. What are the pitfalls i can run into, when trying to implement this ?? I could think of concurrency issues, problem with threads, context, security .. any concrete hints ?? What do you think about that ?? Ulrich Eck net-labs Systemhaus GmbH Ebersberger Str. 46 85570 Markt Schwaben fon: +49-8121-4747-11 fax: +49-8121-4747-77 email: [EMAIL PROTECTED] http://www.net-labs.de ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope RPMs/debs and Linux FHS
Il dom, 2002-10-13 alle 00:28, Chris McDonough ha scritto: > - Jeff's puts some stuff into the current prevailing python's > site-packages directory and some other stuff into /usr/share/zope. > Mine puts nothing into site-packages, and installs all Zope software > into /opt/zope. > > - Jeff's creates an INSTANCE_HOME in /var/zope. Mine creates an > INSTANCE_HOME in /var/opt/zope. I don't know if this is the right > thing but in reading the Linux FHS, it advises to not create > subdirectories of var directly... so I don't. > > - Jeff's puts pid files into /var/run, while mine creates pid files > directly in INSTANCE_HOME/var. perfect. please do that for debian packages too and let /usr for official debian packages of Zope. > - anybody has opinions on the packaging layout. Why is it advantageous > to have many packages rather than one? you can install only what you really need. for example debian as one package for every Product not included in base Zope, so, if i want the CMF i have only to do: apt-get install zope-cmfdefault > - anybody has any opinions of where Zope files distributed via RPMs and > debs should really go, especially wrt to the Linux FHS. I'm not sure > there is a right answer, but I don't know beans about this, so I > figure I'll ask. A file named 'Zope.spec.in' is attached to this > email which is the input file to create a Zope RPM spec file during > the make process, to give a better idea of how this works. /opt and /var/opt is the right place. zope.org is a "software vendor" and stuff from software vendors should gointo /opt. -- Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED] INIT.D Developer [EMAIL PROTECTED] Best friends are often failed lovers. -- Me signature.asc Description: PGP signature
Re: [Zope-dev] Zope RPMs/debs and Linux FHS
This looks GREAT!!
A couple of points:
*) Python 2.2.x ?? This is scheduled for Zope 3 ?? Is there any way this
could find its way in to a 2.x release?
*) Byte compiling: Why not schedule an 'at' job to do the byte compile?
*) Ownership/perms on the 'var' dir, this will need to be the same as the
user Zope runs as, which I assume is not the same as ${zopeuser}
Minor personal request:
*) Is there any way to detect if apache is installed, and have zope run as
the apache user? This would be great for CGI support, etc.
Adrian...
--
Adrian Hungate
EMail: [EMAIL PROTECTED]
Web: http://www.haqa.co.uk
- Original Message -
From: "Chris McDonough" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, October 12, 2002 11:28 PM
Subject: [Zope-dev] Zope RPMs/debs and Linux FHS
> Hi all,
>
> I am working towards a unified Zope configuration and installation
> system on a branch of Zope named the 'chrism-install-branch'.
>
> I have given the buildout process on that branch the ability to create
> an RPM distribution of Zope. I intend later to give the buildout
> process the ability to create Debian .debs as well and maybe Solaris
> packages... I am doing this with the expectation that we might be able
> to provide RPM and .deb distros of Zope from zope.org instead of our
> current "generic Linux as tarball" distro. I haven't looked yet at the
> Debian packaging of Zope (by Gregor Hoffleit), but I intend to do that
> next to get some more ideas.
>
> I know there are already at least two flavors of Zope RPMs which Jeff
> Rush helped to package. There are a number of differences between the
> packaging of the RPMs generated by my branch and the packaging of Jeff's
> RPMs:
>
> - One of Jeff's distros breaks Zope up into many different packages,
> while another installs it as one or two. Mine only has one
> distribution flavor: a single package.
>
> - Jeff's puts some stuff into the current prevailing python's
> site-packages directory and some other stuff into /usr/share/zope.
> Mine puts nothing into site-packages, and installs all Zope software
> into /opt/zope.
>
> - Jeff's creates an INSTANCE_HOME in /var/zope. Mine creates an
> INSTANCE_HOME in /var/opt/zope. I don't know if this is the right
> thing but in reading the Linux FHS, it advises to not create
> subdirectories of var directly... so I don't.
>
> - Jeff's puts pid files into /var/run, while mine creates pid files
> directly in INSTANCE_HOME/var.
>
> - Jeff's puts log files into /var/log while mine puts them into
> INSTANCE_HOME/var.
>
> I am wondering if:
>
> - anybody has opinions on the packaging layout. Why is it advantageous
> to have many packages rather than one?
>
> - anybody has any opinions of where Zope files distributed via RPMs and
> debs should really go, especially wrt to the Linux FHS. I'm not sure
> there is a right answer, but I don't know beans about this, so I
> figure I'll ask. A file named 'Zope.spec.in' is attached to this
> email which is the input file to create a Zope RPM spec file during
> the make process, to give a better idea of how this works.
>
> Thanks!
>
> - C
>
>
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DateTime.rfc822() bug?
Hello Lennart, Friday, October 11, 2002, 2:00:03 PM, you wrote: LR> RFC 2822 (which is the currently valid one, if I understand correctly) LR> specifies the date format to have four digit zone specifications, ie LR> "GMT+0200", while DateTime.rfc822() happily returns "GMT+2". Not that this LR> seems to be any problem, I'm just looking for an answer if this is how it's LR> supposed to be? i can confirm that this is a bug in DateTime.rfc822(), and that rfc-conformant mailclients choke on it aswell.. i believe it has been reported to the lists before , and i believe i have also seen it in the collector.. (the collector seems to be down , but i found this request on google.. http://mail.python.org/pipermail/zope-collector-monitor/2002-May/000652.html ) Your concerns are valid. i usually solve it by use of a small script(python) somewhat resembling this : # params indate fmtstr = "%a, %d %b %Y %X +0200" return indate.strftime(fmtstr) -- Geir Bækholt [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Apology for accidental spamming :-(
Hello, in an attempt to transfer the contents of a mailbox to another location, I made a big mistake resulting in a lot of messages being resent to their original receipients. Please kindly accept my apologies, it will not happen again. Siggy Brentrup -- Log entries for messages erroneously sent to you: 2002-10-13 13:49:32 180hFN-0001VW-00 => [EMAIL PROTECTED] R=lookuphost T=remote_smtp H=mail.python.org [12.155.117.29]* 2002-10-13 13:49:38 180hFK-0001U8-00 => [EMAIL PROTECTED] R=lookuphost T=remote_smtp H=mail.python.org [12.155.117.29]* 2002-10-13 13:49:42 180hFS-0001XD-00 => [EMAIL PROTECTED] R=lookuphost T=remote_smtp H=mail.python.org [12.155.117.29]* 2002-10-13 13:49:46 180hFN-0001VU-00 => [EMAIL PROTECTED] R=lookuphost T=remote_smtp H=mail.python.org [12.155.117.29]* 2002-10-13 13:49:47 180hFK-0001UE-00 => [EMAIL PROTECTED] R=lookuphost T=remote_smtp H=mail.python.org [12.155.117.29]* 2002-10-13 13:49:47 180hFK-0001UA-00 => [EMAIL PROTECTED] R=lookuphost T=remote_smtp H=mail.python.org [12.155.117.29]* 2002-10-13 13:49:50 180hFJ-0001U6-00 => [EMAIL PROTECTED] R=lookuphost T=remote_smtp H=mail.python.org [12.155.117.29]* 2002-10-13 13:49:51 180hFJ-0001U4-00 => [EMAIL PROTECTED] R=lookuphost T=remote_smtp H=mail.python.org [12.155.117.29]* 2002-10-13 13:49:53 180hFK-0001UC-00 => [EMAIL PROTECTED] R=lookuphost T=remote_smtp H=mail.python.org [12.155.117.29]* ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
