Re: [Re: Modified drac support patch]

2001-03-07 Thread Ramiro Morales

Glad to apport my two cents for Cyrus.

Excuse me and please tell me if I'm doing wrong 
posting it to the list, maybe one should 
sent the patches to another place.

Just to point thay you may want to correct 
the description of the patch at the top of the file, 
the first reference to the configuration file to 
be edited refers erroneously to cyrus.conf(5) 
instead of imapd.conf.

And as a bonus a question (for the mailling list):

I'm maintaining RPM packages for Red Hat Linux of 
Cyrus IMAPd, and I'm giving the final retouches to 
the package containing version 2.0.12.

Here is the situation (I hope being clear enough with 
my bad english):

1) Now that drac support is selectable at runtime 
I want to be able to make incorporating the 
drac patch at build time a choice for the builder
(he/she should have libdrac.a available in the filesystem 
at this point).

2) Right now the package build process is using configure 
as it comes with the Cyrus IMAPd distribution.

3) the drac patch needs to rebuild configure from 
the patched configure.in, so it adds two (possibly 
three?) new packages to the list of build 
dependencies: (automake autoconf (and smake?)

I was trying to avoid this and come to the 
following solution:

install automake, autoconf (and smake?) on my system

unpack the Cyrus IMAPd distribution to dir A

unpack the Cyrus IMAPd distribution to dir B

apply the drac patch to dir B

run 
 # rm -f aclocal.m4 configure ; sh SMakefile
on dir B

An now obtain a new drac patch by running

diff -ruN A B

This new drac patch is applied in the %prep
section of the specfile. a diffstat -w 50 
run on  it gives now:

 acconfig.h   |3
 config.h.in  |3
 configure|  511 +
 configure.in |   15
 imap/imapd.c |   52 ++
 imap/pop3d.c |   13
 man/imapd.conf.5 |7
 7 files changed, 378 insertions, 226 deletions

(the high change count in configure is because many 
"echo configure:line number" changes after 
insertion os some lines on it)

I'm doing this because the 'expected audience' for the RPM 
packages is people running Red Hat Linux (as I do), 7 and 
even the coming 7.1 each one with potentially different 
versions (or none at all) of db3 and cyrus-sasl
so I'm recommending people to download and rebuild 
the source RPM in their system rather to use the binary 
one made in my system. But I want to avoid, if 
possible, to force them to install autoconf, 
automake (and smake).

Is it correct or I'm making some wrong assumption(s) ?

TIA !

Ken Murchison [EMAIL PROTECTED] wrote:
 Thanks for the changes.
 
 I have attached a slightly modified version of your patch for 2.0.12.  I
 have also checked a similar patch into CVS for inclusion with future
 releases.
 
 My changes:
 
 - Use value of 'dracinterval' to enable/disable DRAC at runtime.
 
 - Set the default value of 'dracinterval' to 5, since I think that most
 people who compile Cyrus with DRAC support will tend to use it and
 expect it to be on.
 
 - Disable DRAC at runtime if dracd can not be contacted.
 
 Ken
 
 



Get free email and a permanent address at http://www.amexmail.com/?A=1



Re: [Re: Modified drac support patch]

2001-03-07 Thread Ken Murchison



Ramiro Morales wrote:
 
 Glad to apport my two cents for Cyrus.
 
 Excuse me and please tell me if I'm doing wrong
 posting it to the list, maybe one should
 sent the patches to another place.
 
 Just to point thay you may want to correct
 the description of the patch at the top of the file,
 the first reference to the configuration file to
 be edited refers erroneously to cyrus.conf(5)
 instead of imapd.conf.

Made the change in CVS.

Gary, if you are going to add the 2.0.12 patch to your web site, do you
want to make this change?

-- 
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26  Orchard Park, NY 14127
--PGP Public Key--http://www.oceana.com/~ken/ksm.pgp



Re: Modified drac support patch

2001-03-06 Thread Ken Murchison

Thanks for the changes.

I have attached a slightly modified version of your patch for 2.0.12.  I
have also checked a similar patch into CVS for inclusion with future
releases.

My changes:

- Use value of 'dracinterval' to enable/disable DRAC at runtime.

- Set the default value of 'dracinterval' to 5, since I think that most
people who compile Cyrus with DRAC support will tend to use it and
expect it to be on.

- Disable DRAC at runtime if dracd can not be contacted.

Ken


Ramiro Morales wrote:
 
 I'm attaching a modified version of the patch to add
 drac support to Cyrus imapd/pop3d daemons.
 
 It is based in the one included in the contrib
 directory of the 2.0.12 distribution.
 
 I have modified the configuration variables
 used in imapd.conf to be able to specify at runtime
 if one wants to use (or not) drac even when the binary
 used is compiled with drac support (before it was always
 enabled).
 
 Also the interval in minutes between submissions
 to the dracd daemon made by imapd during a user's
 IMAP session is now configurable (previously it was
 fixed to 5 minutes). It is then now possible to
 play with this setting and the -e switch parameter
 passed to the dracd daemon.
 
 The relevant imapd.conf options are
 
 dracinterval: 0
 If nonzero it enables drac support for imapd and pop3d
 indicating then the amount of time in minutes
 between submissions to the dracd daemon made by
 imapd.
 
 drachost: localhost
 The host where the dracd daemon is running.
 
 The instructions to apply it are the same to the
 ones included with the original patch. Just
 take in account the configuration file you modify
 is imapd.conf and not cyrus.conf.
 
 Excuse me for my English.

-- 
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26  Orchard Park, NY 14127
--PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
 drac_auth.patch.gz


Re: Modified drac support patch

2001-03-06 Thread mills

Ken Murchison writes:

I have attached a slightly modified version of your patch for 2.0.12.  I
have also checked a similar patch into CVS for inclusion with future
releases.

Ah, that's good.  I was going to get you two together on this, but
I see that you've already done that.  I didn't like the idea of
maintaining two similar patches, so I'm pleased to see that they
are integrated.


-- 
-Gary Mills--Unix Support--U of M Academic Computing and Networking-