I've been working on getting roundcube mail to work with some of our packages here at Red Hat, by the way you guys have done a great job!
Par for the course with early development I hit some snags, that's to be expected. I'm currently trying to get SMTP to work (we use TLS) and I wasn't getting any error messages. I finally tracked it down to what appears to be a typo in PEAR::isError()
function isError($data) {
return (bool)(is_object($data) &&
(get_class($data) == 'pear_error' ||
is_subclass_of($data, 'pear_error')));
}
The class name is PEAR_Error not pear_error, thus PEAR::isError() always returns false and errors are never caught. Once I fixed that debugging got a whole lot easier :-)
BTW, DB:isError() appears to be fine, also the problem appears to still be in the CVS version of PEAR.php.
On a couple of other notes:
I noticed a lot of the smtp functions don't check for errors. Also it would be nice if when an error is encountered it was logged to a file. log_bug() in bugs.inc seems like the right logging function to call when errors are detected, right? I'm happy to make some patches if you're willing to take them.
Has anyone started work on an RPM yet? If not I would volunteer to do that for you and contribute it.
On Thu, 2006-03-02 at 16:18 -0500, John Dennis wrote:
I noticed a lot of the smtp functions don't check for errors. Also it would be nice if when an error is encountered it was logged to a file. log_bug() in bugs.inc seems like the right logging function to call when errors are detected, right? I'm happy to make some patches if you're willing to take them.
Silly me! I see that raise_error seems to do what is desired, but for some reason in rcube_smtp when there is an error the error message from the subsystem is discarded in favor of a generic message (appended to SMTP_ERROR) such as "Connection failed", which is eventually raised as an error in sendmail.inc. Shouldn't the error handling code in rcube_smtp be doing something like this instead?
// try to connect to server and exit on failure
if (PEAR::isError($result= $SMTP_CONN->connect($smtp_timeout)))
{
$SMTP_CONN = null;
$SMTP_ERROR .= "Connection failed\n" . $result->getMessage();
return FALSE;
}
John Dennis wrote:
I've been working on getting roundcube mail to work with some of our packages here at Red Hat, by the way you guys have done a great job!
Hi John
Par for the course with early development I hit some snags, that's to be expected. I'm currently trying to get SMTP to work (we use TLS) and I wasn't getting any error messages. I finally tracked it down to what appears to be a typo in PEAR::isError()
function isError($data) { return (bool)(is_object($data) && (get_class($data) == 'pear_error' || is_subclass_of($data, 'pear_error'))); }The class name is PEAR_Error not pear_error, thus PEAR::isError() always returns false and errors are never caught. Once I fixed that debugging got a whole lot easier :-)
Thanks for the hint. As read in the PHP manual, the class name is returned in lower case in PHP 4 and in it's original notation in PHP 5. I will update the PEAR class to provide full PHP 5 compatibility.
BTW, DB:isError() appears to be fine, also the problem appears to still be in the CVS version of PEAR.php.
On a couple of other notes:
I noticed a lot of the smtp functions don't check for errors. Also it would be nice if when an error is encountered it was logged to a file. log_bug() in bugs.inc seems like the right logging function to call when errors are detected, right? I'm happy to make some patches if you're willing to take them.
Has anyone started work on an RPM yet? If not I would volunteer to do that for you and contribute it.
As far as I know there's nobody who started to make an RPM package of RoundCube. I'm not sure if it's too early to create one but I would appreciate it.
Regards, Thomas
On Fri, 2006-03-03 at 17:13 +0100, Thomas Bruederli wrote:
John Dennis wrote:
Has anyone started work on an RPM yet? If not I would volunteer to do that for you and contribute it.
As far as I know there's nobody who started to make an RPM package of RoundCube. I'm not sure if it's too early to create one but I would appreciate it.
FYI, I've begun work on installation support.
First task which is almost complete is to add GNU autoconf support so there will be a "configure" script with the ability to specify installation parameters so that one can then do:
/configure [optional args] make install
Once that is complete wrapping it in an RPM should be fairly straight forward.
John Dennis a écrit :
FYI, I've begun work on installation support.
... Once that is complete wrapping it in an RPM should be fairly straight forward.
Great ! This will allow faster and simpler distribution and installation of RoundCube on Linux systems. Good luck !
This would be mad. A generic RPM would be great!
And can someone clarify what no arch is? Does that mean no architecture
ie. there are no binaries in the package?
On Fri, 17 Mar 2006 08:58:00 +1100, Aurélien Pocheville
aurelien.pocheville@haptique.com wrote:
John Dennis a écrit :
FYI, I've begun work on installation support.
... Once that is complete wrapping it in an RPM should be fairly straight forward.
Great ! This will allow faster and simpler distribution and installation
of RoundCube on Linux systems. Good luck !
On Fri, 17 Mar 2006, Chris Fordham (chris@xhost.com.au) wrote:
This would be mad. A generic RPM would be great!
Just as long as there is a standard .tar.gz for all us people who don't use RPM.
And can someone clarify what no arch is? Does that mean no architecture ie. there are no binaries in the package?
Please correct me if i'm wrong, but doesn't an RPM have a pre-defined structure for where the files go?
How exactly could you produce an RPM to put RC in a webroot if you don't know where that webroot is when you built the RPM?
And if is there is a standard webroot for RPM based distributions, what about the people who don't install RC system wide? Or in a virtual hosted domain?
I could be wrong in my assumptions about RPM (given that I tend to avoid anything RPM related like the plague), but I just can't see how it would work.
D.
Darren Austin wrote:
On Fri, 17 Mar 2006, Chris Fordham (chris@xhost.com.au) wrote:
This would be mad. A generic RPM would be great!
Just as long as there is a standard .tar.gz for all us people who don't use RPM.
And can someone clarify what no arch is? Does that mean no architecture ie. there are no binaries in the package?
Normally means no binaries, not architecture specific.
Please correct me if i'm wrong, but doesn't an RPM have a pre-defined structure for where the files go?
How exactly could you produce an RPM to put RC in a webroot if you don't know where that webroot is when you built the RPM?
Yes. RPMs are normally built for a particular distro which will have the webroot in a predefined (by default) location.
And if is there is a standard webroot for RPM based distributions, what about the people who don't install RC system wide? Or in a virtual hosted domain?
I could be wrong in my assumptions about RPM (given that I tend to avoid anything RPM related like the plague), but I just can't see how it would work.
This is why I never use RPMs for web based packages as my sites are ALL virtual hosted, normally under my home dir somewhere.
On Fri, 17 Mar 2006 00:41:18 +0000, Dean Earley dean@earlsoft.co.uk wrote:
Darren Austin wrote:
Yes. RPMs are normally built for a particular distro which will have the webroot in a predefined (by default) location.
The could be built to stay in, for example, /usr/share/roundcube/, and have some http alias point there. In this case, the rpm should also have a file /etc/httpd/conf.d/roundcube.conf with RC configuration.
Yes, I don't see how RPM is going to help.. but what I was hoping for is a web based PHP installer/configurator that works once you drop the files where you want them, and point your browser at it. Once config is done, it writes your config.php, and it deletes the installer files for security reasons. Many web apps have this to make installing something other than a chore.
-- Robi
Hi,
On 17 Mar 2006, at 18:40, Robi wrote:
Yes, I don't see how RPM is going to help..
On a larger scale (ie server-wide deployment or larger) point of
view, typing
yum install roundcube
or, in my case,
emerge roundcube
is so much nicer than installing everything myself and making sure
all dependencies are pulled in - and as an added bonus, I can have
upgrades happen very easily like so
emerge -u roundcube
Yours, Craig -- Craig Webster | t: +44 (0)131 516 8595 | e: craig@xeriom.net Xeriom.NET | f: +44 (0)131 661 0689 | w: http://xeriom.net
"Te audire non possum. Musa sapientum fixa est in aure" - Unknown
I think this is a great method and would like to see it done!
On Fri, 17 Mar 2006 20:07:00 +1100, Martin Marques
martin@bugs.unl.edu.ar wrote:
On Fri, 17 Mar 2006 00:41:18 +0000, Dean Earley dean@earlsoft.co.uk
wrote:Darren Austin wrote:
Yes. RPMs are normally built for a particular distro which will have the webroot in a predefined (by default) location.
The could be built to stay in, for example, /usr/share/roundcube/, and
have some http alias point there. In this case, the rpm should also have
a file /etc/httpd/conf.d/roundcube.conf with RC configuration.
On Sat, 18 Mar 2006 00:55:57 +0000, Craig Webster craig@xeriom.net wrote:
Hi,
On 17 Mar 2006, at 18:40, Robi wrote:
Yes, I don't see how RPM is going to help..
On a larger scale (ie server-wide deployment or larger) point of view, typing yum install roundcube or, in my case, emerge roundcube is so much nicer than installing everything myself and making sure all dependencies are pulled in - and as an added bonus, I can have upgrades happen very easily like so emerge -u roundcube
I think this is usually up to distros, and that's why you see FC RPMs vs SUSE RPMs. Sometimes you'll even have different ones for Debian and Ubutnu, even though they're related there can always be diffs as far as webroot, web user, web group, etc.
Looks like the maintainer of the FreeBSD port is keeping up a bit too:
http://www.freshports.org/mail/roundcube/
It's from Feb 19th, but it's not as old as it could be. As for pulling in all the dependencies, yeah, that's what makes apt-get, yum, portupgrade, emerge, apt-rpm so nice nowadays; having a base pkg allows all the dists to integrate with that.
P
http://fak3r.com - you dont have to kick it
On Fri, 2006-03-17 at 00:16 +0000, Darren Austin wrote:
On Fri, 17 Mar 2006, Chris Fordham (chris@xhost.com.au) wrote:
This would be mad. A generic RPM would be great!
Just as long as there is a standard .tar.gz for all us people who don't use RPM.
And can someone clarify what no arch is? Does that mean no architecture ie. there are no binaries in the package?
Please correct me if i'm wrong, but doesn't an RPM have a pre-defined structure for where the files go?
How exactly could you produce an RPM to put RC in a webroot if you don't know where that webroot is when you built the RPM?
And if is there is a standard webroot for RPM based distributions, what about the people who don't install RC system wide? Or in a virtual hosted domain?
I could be wrong in my assumptions about RPM (given that I tend to avoid anything RPM related like the plague), but I just can't see how it would work.
The answer is installation is divided into two parts. The first part is the use the standard GNU autotools which produce a "configure" script. Many people are already familar with the following drill:
% ./configure [optional args] % make install
The production of the configure script is 90% of the installation support work and is completely INDEPENDENT of RPM. If you want to install in a different location (e.g. /myWebRoot) its as simple as:
% ./configure --with-pkgdir=/myWebRoot % make install
RPM's are for distributions which want to enforce standard locations for consistency within the distribution (and to perform some additional installation steps). In essence an RPM just "wraps" the configure script with specific arguments to "configure" (O.K., thats a bit simplified but essentially true).
If you're using a distribution an RPM usually is the path of least resistence to getting a working installation. If you have other needs by all means skip the RPM and just use "configure" directly. The proposed solution serves both needs well.
BTW, almost done with the work ...
Could someone tell me where the code is for the js that creates info
messages like loading and message sent? Or the CSS that controls the
appearance? I know that I am being VERY picky, but it bothers me that
the box extends into the icons.
Thanks, Ken
On Tue, 2006-03-21 at 10:05 -0500, John Dennis wrote:
The answer is installation is divided into two parts. The first part is the use the standard GNU autotools which produce a "configure" script. BTW, almost done with the work ...
O.K. I've completed the autoconf support. The rpm needs a little bit more work, but I've been distracted by other work commitments and I'll be out of town for a week so I wanted to contribute this work before too much time went by or there were too many changes from the 0.1-beta release which formed the base I worked from. I went to SourceForge project page and looked for a "Patches" page, but there wasn't one so I created bug 1460202 and added a patch and tar file there along with comments.
Of note there is new shell script SQL/roundcube_mysql which will perform initial setup of the MySQL database, validate the MySQL installation, and allow one to set the roundcube MySQL password.
Documentation can be found in the file autoconf_howto located in the root directory. It explains what developers will need to know as they work with the source tree and what end users need to know to perform an installation.
At the moment the configure script supports these installation options:
--with-pkgdir=DIR primary installation directory --with-docdir=DIR installation directory for documentation & examples
I fully expect the configure script will need more tweaking and features, this is just a start. It should for instance allow for the selection of the desired SQL database. I also expect as others use the new support they will discover some problems I didn't hit and I'll be happy to correct them.
Also of note is the fact the main.inc.php.dist and db.inc.php.dist files in configure now have some of there parameters initialized via the results of "configure". There are more opportunities here for updating these files with parameters from "configure" so post installation is less demanding.
After I return and as time permits I will complete the RPM. I currently have a spec file written and it builds the RPM using the autoconf support I created. But I have not had a chance to test it yet. I also need to complete an /etc/httpd/conf.d/roundcube.conf file so roundcube will work with Apache out of the box after RPM installation. FWIW, the approach taken is for roundcube to install into its own directory outside the document root (but inside the tree owned by Apache, this is needed for proper SELinux file labeling) and then to use mod_rewrite to point the URL's to the installation directory. This has the nice property of keeping things out of the document root and nicely partitioned, and allows for the site to select its preferred URL to get to roundcube (another item to be added to configure).
-
Aurélien Pocheville -
Chris Fordham -
Craig Webster -
Darren Austin -
Dean Earley -
John Dennis -
Ken Samland -
Martin Marques -
phil -
Robi -
Thomas Bruederli