Jake Vickers | 1 Feb 2010 04:39
Favicon

[qmailtoaster-devel] Stable packages repo

Before I run off to bed, wanted to get a message out to you real quick 
about the stable packages repo.
You can check them out from subversion by using the following command:
svn co http://qmailtoaster.com/qmt-stable stable

This will create a new folder called "stable" and download all of the 
current spec files, source code, and other utilities to your system.
I've added the email-test script to the tools dir as well, and hope to 
write some "helper" scripts soon for the development process and add 
them to the tools directory. I know Steve had mentioned that he had some 
tools that we would find useful and hopefully he will share them with us.
The current spec files include support for Fedora 12, but are not on the 
web site at this time. I've been holding off for a couple reasons, the 
latest of which is the release of Spamassassin 3.3.x. Depending on how 
some tests go (and test by Steve), I may release the packages with F12 
support before updating SA, but I'd like to roll them out at the same time.

Anyway, off to bed.
Eric Shubert | 1 Feb 2010 05:15
Favicon

Re: [qmailtoaster-devel] Spamassassin 3.3.x released

Steve Huff wrote:
> 
> On Jan 31, 2010, at 1:57 PM, Jake Vickers wrote:
> 
>> There is a list of new CPAN requirements:
>>
>>  - minimum required version of ExtUtils::MakeMaker is 6.17;
>>  - modules now required: Time::HiRes, NetAddr::IP (4.000 or later),
>>    Archive::Tar (1.23 or later), IO::Zlib;
>>  - minimal version of Mail::DKIM is 0.31 (preferred: 0.37 or later);
>>    expect some tests in t/dkim2.t to fail with versions older than 
>> 0.36_5;
>>  - no longer used: Mail::DomainKeys, Mail::SPF::Query;
>>  - either Digest::SHA or the older Digest::SHA1 is required, though
>>    note that the DKIM plugin requires Digest::SHA for sha256 hashes
>>    and Razor agents still need Digest::SHA1;
>>  - some IPv6 functionality requires IO::Socket::INET6;
> 
> 
> i'll do an audit of the modules currently available in rpmforge and see 
> if any of these are going to be a problem for RHEL4/5.
> 
> -steve
> 

Thanks Steve. I hope that we can get all of the modules in rpm format so 
we don't need to use CPAN.

Let's not forget to keep our eyes on the dreaded MakeMaker. It was 
MakeMaker v6.44 that created havoc with spamassassin-toaster. I wonder 
(Continue reading)

Eric Shubert | 1 Feb 2010 05:17
Favicon

Re: [qmailtoaster-devel] Providing zlib

Jake Vickers wrote:
> Unless someone has any objections or reasons why it should be retained, 
> I am going to move the zlib package to a different dir that is not 
> included in the package list on the main site.
> I am also not going to include it in the subversion repo for the stable 
> branch. I think all the distros have had a sufficient version since FC3 
> or so.

Yay!

Can we move djbdns off to the side somewhere as well? That's the only 
other non-toaster package in the lot. They both made things more 
difficult in qtp-newmodel than they otherwise would be.

--

-- 
-Eric 'shubes'
Jacob Vickers | 1 Feb 2010 16:04
Favicon

Re: [qmailtoaster-devel] Providing zlib

> Jake Vickers wrote:
>> Unless someone has any objections or reasons why it should be retained,
>> I am going to move the zlib package to a different dir that is not
>> included in the package list on the main site.
>> I am also not going to include it in the subversion repo for the stable
>> branch. I think all the distros have had a sufficient version since FC3
>> or so.
>
> Yay!
>
> Can we move djbdns off to the side somewhere as well? That's the only
> other non-toaster package in the lot. They both made things more
> difficult in qtp-newmodel than they otherwise would be.
>
> --
> -Eric 'shubes'
>
>

With the previous discussion with making some packages "optional" (such as
the web based utilities - qmailadmin, webmail, etc.) I think we're going
to eventually need an "Optional" package section for these utilities. I
think we need to have a long and in-depth discussion on this however,
since webmail and administration utilities for the mail system that new
admins are installing are very important to their installation and
environment and we need a defined (and easy!!!!) way to get things
installed for them. Either way I will be removing any dependencies for
these web based and "optional" utilities from the core packages (realize
this also includes ezmlm....)
As far as djbdns, I really do not care about this one either way. I do not
(Continue reading)

Michael Colvin | 1 Feb 2010 17:36
Favicon

RE: [qmailtoaster-devel] Providing zlib

> -----Original Message-----
> From: Jacob Vickers [mailto:jake <at> qmailtoaster.com]
> Sent: Monday, February 01, 2010 7:05 AM
> To: qmailtoaster-devel <at> qmailtoaster.com
> Subject: Re: [qmailtoaster-devel] Providing zlib
> 
> > Jake Vickers wrote:
> >> Unless someone has any objections or reasons why it should be retained,
> >> I am going to move the zlib package to a different dir that is not
> >> included in the package list on the main site.
> >> I am also not going to include it in the subversion repo for the stable
> >> branch. I think all the distros have had a sufficient version since FC3
> >> or so.
> >
> > Yay!
> >
> > Can we move djbdns off to the side somewhere as well? That's the only
> > other non-toaster package in the lot. They both made things more
> > difficult in qtp-newmodel than they otherwise would be.
> >
> > --
> > -Eric 'shubes'
> >
> >
> 
> 
> With the previous discussion with making some packages "optional" (such as
> the web based utilities - qmailadmin, webmail, etc.) I think we're going
> to eventually need an "Optional" package section for these utilities. I
> think we need to have a long and in-depth discussion on this however,
(Continue reading)

Eric Shubert | 1 Feb 2010 18:05
Favicon

Re: [qmailtoaster-devel] Providing zlib

Jacob Vickers wrote:
>> Jake Vickers wrote:
>>> Unless someone has any objections or reasons why it should be retained,
>>> I am going to move the zlib package to a different dir that is not
>>> included in the package list on the main site.
>>> I am also not going to include it in the subversion repo for the stable
>>> branch. I think all the distros have had a sufficient version since FC3
>>> or so.
>> Yay!
>>
>> Can we move djbdns off to the side somewhere as well? That's the only
>> other non-toaster package in the lot. They both made things more
>> difficult in qtp-newmodel than they otherwise would be.
>>
>> --
>> -Eric 'shubes'
>>
>>
> 
> 
> With the previous discussion with making some packages "optional" (such as
> the web based utilities - qmailadmin, webmail, etc.) I think we're going
> to eventually need an "Optional" package section for these utilities. I
> think we need to have a long and in-depth discussion on this however,
> since webmail and administration utilities for the mail system that new
> admins are installing are very important to their installation and
> environment and we need a defined (and easy!!!!) way to get things
> installed for them. Either way I will be removing any dependencies for
> these web based and "optional" utilities from the core packages (realize
> this also includes ezmlm....)
(Continue reading)

Eric Shubert | 1 Feb 2010 18:15
Favicon

Re: [qmailtoaster-devel] Providing zlib

Michael Colvin wrote:
>> -----Original Message-----
>> From: Jacob Vickers [mailto:jake <at> qmailtoaster.com]
>> Sent: Monday, February 01, 2010 7:05 AM
>> To: qmailtoaster-devel <at> qmailtoaster.com
>> Subject: Re: [qmailtoaster-devel] Providing zlib
>>
>>> Jake Vickers wrote:
>>>> Unless someone has any objections or reasons why it should be retained,
>>>> I am going to move the zlib package to a different dir that is not
>>>> included in the package list on the main site.
>>>> I am also not going to include it in the subversion repo for the stable
>>>> branch. I think all the distros have had a sufficient version since FC3
>>>> or so.
>>> Yay!
>>>
>>> Can we move djbdns off to the side somewhere as well? That's the only
>>> other non-toaster package in the lot. They both made things more
>>> difficult in qtp-newmodel than they otherwise would be.
>>>
>>> --
>>> -Eric 'shubes'
>>>
>>>
>>
>> With the previous discussion with making some packages "optional" (such as
>> the web based utilities - qmailadmin, webmail, etc.) I think we're going
>> to eventually need an "Optional" package section for these utilities. I
>> think we need to have a long and in-depth discussion on this however,
>> since webmail and administration utilities for the mail system that new
(Continue reading)

Michael Colvin | 1 Feb 2010 18:43
Favicon

RE: [qmailtoaster-devel] Providing zlib

> 
> Michael Colvin wrote:
> >> -----Original Message-----
> >> From: Jacob Vickers [mailto:jake <at> qmailtoaster.com]
> >> Sent: Monday, February 01, 2010 7:05 AM
> >> To: qmailtoaster-devel <at> qmailtoaster.com
> >> Subject: Re: [qmailtoaster-devel] Providing zlib
> >>
> >>> Jake Vickers wrote:
> >>>> Unless someone has any objections or reasons why it should be
> retained,
> >>>> I am going to move the zlib package to a different dir that is not
> >>>> included in the package list on the main site.
> >>>> I am also not going to include it in the subversion repo for the
> stable
> >>>> branch. I think all the distros have had a sufficient version since
> FC3
> >>>> or so.
> >>> Yay!
> >>>
> >>> Can we move djbdns off to the side somewhere as well? That's the only
> >>> other non-toaster package in the lot. They both made things more
> >>> difficult in qtp-newmodel than they otherwise would be.
> >>>
> >>> --
> >>> -Eric 'shubes'
> >>>
> >>>
> >>
> >> With the previous discussion with making some packages "optional" (such
(Continue reading)

Martin Waschbuesch | 1 Feb 2010 19:00
Picon

RE: [qmailtoaster-devel] Providing zlib

Hi there,

Zitat von Michael Colvin <mcolvin <at> norcalisp.com>:

> I think one of the "strengths" of DJBDNS was it's light-weight nature and
> simplicity, versus say BIND.  In my scenario, I just want something secure,
> fast and reliable to function as a caching nameserver for RBL lookups, etc.
> I've always used DJBDNS for this, at least recently, but have used BIND too,
> it just seemed DJBDNS was better suited, but I'm open to any options, I'm
> not married to DJBDNS.
>
> My guess is, unfortunately, that most people don't use caching DNS, and
> simply rely on their ISP's DNS, or another server that they have some flavor
> of DNS running on.

I agree - I could live with bind or whatever else, too, but I always  
used djbdns on toasters for caching DNS. No regrets ever.
On the other hand, if we could move towards using as many system  
provided packages (to benefit from easy package updating for security  
related stuff / etc.) that would also be nice.
Perhaps the best way would be to go for the second approach and keep a  
wiki page on options such as djbdns?

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Attachment: application/pgp-keys, 1348 bytes
---------------------------------------------------------------------
(Continue reading)

Eric Shubert | 1 Feb 2010 19:06
Favicon

Re: [qmailtoaster-devel] Providing zlib

Michael Colvin wrote:
>> Michael Colvin wrote:
>>>> -----Original Message-----
>>>> From: Jacob Vickers [mailto:jake <at> qmailtoaster.com]
>>>> Sent: Monday, February 01, 2010 7:05 AM
>>>> To: qmailtoaster-devel <at> qmailtoaster.com
>>>> Subject: Re: [qmailtoaster-devel] Providing zlib
>>>>
>>>>> Jake Vickers wrote:
>>>>>> Unless someone has any objections or reasons why it should be
>> retained,
>>>>>> I am going to move the zlib package to a different dir that is not
>>>>>> included in the package list on the main site.
>>>>>> I am also not going to include it in the subversion repo for the
>> stable
>>>>>> branch. I think all the distros have had a sufficient version since
>> FC3
>>>>>> or so.
>>>>> Yay!
>>>>>
>>>>> Can we move djbdns off to the side somewhere as well? That's the only
>>>>> other non-toaster package in the lot. They both made things more
>>>>> difficult in qtp-newmodel than they otherwise would be.
>>>>>
>>>>> --
>>>>> -Eric 'shubes'
>>>>>
>>>>>
>>>> With the previous discussion with making some packages "optional" (such
>> as
(Continue reading)


Gmane