-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Wouter van der Schagt wrote:
> When using vpopmail 5.4.28-devel. I'm getting the following error message:
>
> "configure: error: Unable to find your MySQL inc dir, specify
> --enable-incdir."
>
> This message appeared when the development files for MySQL were not
> installed, but the directory existed. Installing the necessary files
> worked, but perhaps the message could be a little different because the
> option 'was' specified. Anyway, this is only a minor issue.
Because the configure script uses existing autoconf tool calls for determining
if the development files for MySQL are existing, it wouldn't make sense to
modify
this. The test is testing if it can link to MySQL at standard locations. If
you
don't have the development files, it matters little whether the directory exists
or not.
However, I do agree it could say something along the lines of 'Unable to find
MySQL
development headers', rather than that it could not find the directory.
> --- 2 ---
>
> The status at the end of the configure, shows 5.4.27, even though it is
> 5.4.28, again - minor.
Really? Ha! I'll fix that :)
> --- 3 ---
>
> In 5.5 I noticed that the tcp.smtp file was moved to
> /home/vpopmail/etc/tcp.smtp instead of /etc/tcp.smtp. Is this the new
> default behavior in 5.4.28 as well? This would probably mean that people
> will have to update their existing /var/qmail/bin/qmailctl file for the
> cdb command to reload the rules?
The 5.5 branch is working in FHS compliance, and it's a bit complex because
so much of vpopmail has been built on /home/vpopmail. Normally vpopmail
looks for an existing tcp.smtp file and then favors that over it's desired
/home/vpopmail/etc location. Adding the FHS favoring in also caused some
pathing issues with the tcp.smtp file. Just force it for now. This will
be worked out as 5.5 becomes the devel version.
> The previously reported error message: "Warning: Failed while attempting
> to delete domain from auth backend" also appears in 5.4.28 when adding
> and immediately deleting a domain. I believe the cause is also the same
> as in the 5.4.25 and 5.5 branch. If I remember correctly a strace
> revealed a failing SQL query on a non existing table. I can look it up
> if necessary, just let me know.
Please do because I can't remember what happened with this.
> What is the default behavior of the newly implemented domain quota's in
> 5.4.28? is it on or off by default, and if on, how can it be controlled?
Domain quotas are *not* on by default in 5.4.28 because they haven't been
in so long. Also, 5.5 differs greatly in quota handling, and 5.4.28 does
not have these changes, so I felt it best to leave 5.4.28 with domain quotas
off by default.
> Last question: Is there any major change that could break an existing
> 5.4.25 installation? I'm considering to upgrade a production server to
> 5.4.28 status in order to test the usage daemon, the 2 GB per mailbox
> fix and possibly the domain quotas.
I'm not aware of any at this time. The point of 5.4.28 was to fix up
some big problems with the quota system, solve any remaining large
bugs, and finally, to release a final 5.4 tree version so the new
5.5 tree could go development with it's *many*, *big* changes.
- --
/*
Matt Brookings <m...@inter7.com> GnuPG Key FAE0672C
Software developer Systems technician
Inter7 Internet Technologies, Inc. (815)776-9465
*/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkpvEvkACgkQIwet2/rgZyyJBwCePvmPKroW7dZwN1oxRLIMIETd
6PIAoIuZvNavdlsmN2MIImm4V43YV18E
=gMl0
-----END PGP SIGNATURE-----
