Mailing List Archive

Status of 2.0rc3?
Ilja,

Have you checked out my patch since 2.0rc2 on SourceForge? I'd like to see
this patch be the impetus for the 2.0rc3 release, as it adds much robustness
that will need a few weeks of user testing to ensure that it is real-world ready.

Also, I got my Alpha out of storage and have found that the MD5 code does not
segfault. Amusingly, the last time I compiled DBMail on this machine was
1.0rc3, when I wrote the authldap code :-) I have not yet tried a memory
debugger to confirm that it isn't just working by mistake, though.

Please let us know if you're waiting on 2.0rc3 until the MD5 issue is
resolved; I'm sure that more people would suddenly be eager to learn MD5
hashing if a new or fixed implementation is what we need to continue towards a
2.0 release ;-)

Aaron
RE: Status of 2.0rc3? [ In reply to ]
Hey,

Speaking of SourceForge and testing on other 64bit architectures,
they provide a very wide selection of hardware and OS's for just
this sort of testing. I'm sure if desired, that could be enabled
for the dbmail project pretty easily.



---- Original Message ----
From: Aaron Stone <dbmail-dev@dbmail.org>
To: <dbmail-dev@dbmail.org>
Subject: [Dbmail-dev] Status of 2.0rc3?
Sent: Fri, 20 Feb 2004 17:39:38 -0000

>
> Ilja,
>
> Have you checked out my patch since 2.0rc2 on SourceForge? I'd like
to see
> this patch be the impetus for the 2.0rc3 release, as it adds much
robustness
> that will need a few weeks of user testing to ensure that it is
real-world ready.
>
> Also, I got my Alpha out of storage and have found that the MD5 code
does not
> segfault. Amusingly, the last time I compiled DBMail on this machine was
> 1.0rc3, when I wrote the authldap code :-) I have not yet tried a memory
> debugger to confirm that it isn't just working by mistake, though.
>
> Please let us know if you're waiting on 2.0rc3 until the MD5 issue is
> resolved; I'm sure that more people would suddenly be eager to learn MD5
> hashing if a new or fixed implementation is what we need to continue
towards a
> 2.0 release ;-)
>
> Aaron
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>
-- End Original Message --


--
Jesse Norell

administrator@kci.net is not my email address;
change "administrator" to my first name.
--
RE: Status of 2.0rc3? [ In reply to ]
You're quite right! I've never used the Compile Farm, but I'll check it out
next week when I have some more time. Naturally, anyone else who can beat me
to it, should :-P

(From the SF.net FAQ) What OS platforms and hardware architectures are
represented in the SourceForge.net Compile Farm?

Architecture Processor OS Distribution
AMD64 AMD Opteron Linux 2.4 SuSE 8 ES
PowerPC Apple Mac G4 Mac OS X Mac OS X Server with Fink
x86 dual Intel Pentium III Linux 2.4 Red Hat Linux 7.3
x86 dual Intel Pentium III Linux 2.2 Debian GNU/Linux 2.2
Alpha DEC Alpha EV67 Linux 2.2 Debian GNU/Linux 3.0
Sparc64 Sun Ultra 60 Linux 2.4 Debian GNU/Linux 3.0
Sparc Sun UE R220 Solaris Sun Solaris 8
StrongARM CerfCube SA1110 Linux 2.4 Debian GNU/Linux 3.0

Aaron


""Jesse Norell"" <jesse@kci.net> said:

>
> Hey,
>
> Speaking of SourceForge and testing on other 64bit architectures,
> they provide a very wide selection of hardware and OS's for just
> this sort of testing. I'm sure if desired, that could be enabled
> for the dbmail project pretty easily.
>
>
>
> ---- Original Message ----
> From: Aaron Stone <dbmail-dev@dbmail.org>
> To: <dbmail-dev@dbmail.org>
> Subject: [Dbmail-dev] Status of 2.0rc3?
> Sent: Fri, 20 Feb 2004 17:39:38 -0000
>
> >
> > Ilja,
> >
> > Have you checked out my patch since 2.0rc2 on SourceForge? I'd like
> to see
> > this patch be the impetus for the 2.0rc3 release, as it adds much
> robustness
> > that will need a few weeks of user testing to ensure that it is
> real-world ready.
> >
> > Also, I got my Alpha out of storage and have found that the MD5 code
> does not
> > segfault. Amusingly, the last time I compiled DBMail on this machine was
> > 1.0rc3, when I wrote the authldap code :-) I have not yet tried a memory
> > debugger to confirm that it isn't just working by mistake, though.
> >
> > Please let us know if you're waiting on 2.0rc3 until the MD5 issue is
> > resolved; I'm sure that more people would suddenly be eager to learn MD5
> > hashing if a new or fixed implementation is what we need to continue
> towards a
> > 2.0 release ;-)
> >
> > Aaron
> > _______________________________________________
> > Dbmail-dev mailing list
> > Dbmail-dev@dbmail.org
> > http://twister.fastxs.net/mailman/listinfo/dbmail-dev
> >
> -- End Original Message --
>
>
> --
> Jesse Norell
>
> administrator@kci.net is not my email address;
> change "administrator" to my first name.
> --
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>



--
Re: Status of 2.0rc3? [ In reply to ]
Hi,

I've had kind of strange week last week. Three days of working mostly on
other projects, followed by two days of being ill and staying home..
So, I didn't do a lot of DBMail related work last week.
Aaron Stone wrote:
> Ilja,
>
> Have you checked out my patch since 2.0rc2 on SourceForge? I'd like to see
> this patch be the impetus for the 2.0rc3 release, as it adds much robustness
> that will need a few weeks of user testing to ensure that it is real-world ready.
I'll check it out today :)
>
> Also, I got my Alpha out of storage and have found that the MD5 code does not
> segfault. Amusingly, the last time I compiled DBMail on this machine was
> 1.0rc3, when I wrote the authldap code :-) I have not yet tried a memory
> debugger to confirm that it isn't just working by mistake, though.
OK. So it might be some strange Opteron-only problem. Still, it's a
matter that should be solved somehow, to make sure DBMail also runs well
on Opteron machines (I keep reading reports on big hardware vendors
adding Opteron-based machines to their lists, so we need to support them).
>
> Please let us know if you're waiting on 2.0rc3 until the MD5 issue is
> resolved; I'm sure that more people would suddenly be eager to learn MD5
> hashing if a new or fixed implementation is what we need to continue towards a
> 2.0 release ;-)
I guess your solution, using the RSA-code would be best. I'll have a
look at all the licenses involved.

Ilja
Re: Status of 2.0rc3? [ In reply to ]
Ilja Booij <ilja@ic-s.nl> said:

> Hi,
>
> I've had kind of strange week last week. Three days of working mostly on
> other projects, followed by two days of being ill and staying home..
> So, I didn't do a lot of DBMail related work last week.

Hope you're feeling better!

> Aaron Stone wrote:
> > Ilja,
> >
> > Have you checked out my patch since 2.0rc2 on SourceForge? I'd like to
> > see this patch be the impetus for the 2.0rc3 release, as it adds much
> > robustness that will need a few weeks of user testing to ensure that
> > it is real-world ready.
> I'll check it out today :)

Thanks!

> >
> > Also, I got my Alpha out of storage and have found that the MD5 code
> > does not segfault. Amusingly, the last time I compiled DBMail on this
> > machine was 1.0rc3, when I wrote the authldap code :-) I have not yet
> > tried a memory debugger to confirm that it isn't just working by mistake,
> > though.
> OK. So it might be some strange Opteron-only problem. Still, it's a
> matter that should be solved somehow, to make sure DBMail also runs well
> on Opteron machines (I keep reading reports on big hardware vendors
> adding Opteron-based machines to their lists, so we need to support them).

I signed up for the SourceForge Compile Farm last Friday, and they have an
Opteron available for testing. With two data points, we can try to see if it's
specifically the processor or perhaps something at the software level (bad
libraries, compiler, who knows).

> >
> > Please let us know if you're waiting on 2.0rc3 until the MD5 issue is
> > resolved; I'm sure that more people would suddenly be eager to learn MD5
> > hashing if a new or fixed implementation is what we need to continue
> > towards a 2.0 release ;-)
> I guess your solution, using the RSA-code would be best. I'll have a
> look at all the licenses involved.

Definitely make sure that the licenses aren't going to be a problem.

--