> > On the topic of releasing, why isn't qpsmtpd released to CPAN?
>
> Because we never really got it easily installable via the whole
> "Makefile.PL" route.
Any specific problems? Is it because qpsmtpd can be installed in several ways,
or is it just an itch nobody really cared to scratch yet?
-
On Jan 3, 2009, at 2:10, Kaare Rasmussen wrote:
On the topic of releasing, why isn't qpsmtpd released to CPAN?
Because we never really got it easily installable via the whole
"Makefile.PL" route.
Any specific problems? Is it because qpsmtpd can be installed in
several ways,
or is it just
On Sun, 2009-04-01 at 06:41 -0800, Ask Bjørn Hansen wrote:
> I'd like us to move towards doing a "proper" standard-
> ish install as the default.
You need a post-install configuration tool (script to start) as well.
--
--gh
The code feeds the results of $session->config('me') to
sprintf as part of the format string. In practice, this is
probably not a problem since hostnames don't contain percent
signs. However, it triggers a taint warning in perl 5.10,
making cram-md5 auth unusable.
This patch rewrites the sprintf t
The code feeds the results of $session->config('me') to
sprintf as part of the format string. In practice, this is
probably not a problem since hostnames don't contain percent
signs. However, it triggers a taint warning in perl 5.10,
making cram-md5 auth unusable.
This patch rewrites the sprintf t
>
> So: Patches to improve Makefile.PL and a standard install are welcome.
Do we want to end up somewhere where Makefile.PL is required?
Personally, I like that the untar and run is the default.
-R
This is really just papering over the issue, as it doesn't actually
validate the contents of 'me', which could still potentially contain
bad data. But as this doesn't actually make anything *worse* and
fixes your case, applied as r967.
The "right" way to fix this is a lot more work involves abs
On Sun, Jan 04, 2009 at 10:38:57PM -0800, Robert Spier wrote:
> This is really just papering over the issue, as it doesn't actually
> validate the contents of 'me', which could still potentially contain
> bad data. But as this doesn't actually make anything *worse* and
> fixes your case, applied
