> As for me well, to paraphrase a line from "The Tao of Programming",
> "I do not wish to learn another version control system!".
Amen.
> I've already had to learn git for a work project, and once I've gotten
> into it I've been pretty happy with it. I haven't heard anyone really
> scream a
>because sasl.h is in /usr/include/sasl/sasl.h
Whoops ... okay, I'll fix that.
>You have some reason for wanting to move away from
>savannah? (they support arch, bzr, git, mercurial
>and svn.)
Huh, shows what I know. If savannah supports git, then that's fine
with me.
As for me well, to p
> It need not promise
> perfect backward compatibility, I would think reason enough
> to start anew.
Already done, 15 years ago. It's called webmail.
And thanks for spoiling what was until now a pleasant Friday
evening :-P
___
Nmh-workers mailing lis
>I would expect most distros to use either /usr/include or /opt/mumble.
>The mumble might be standardized by now, I dunno.Perhaps I'm
>far enough removed from distros these days that I'm wrong; that would
>be nice.
Note that with the OLD autoconf code, if you actually did
--with-cyrus-sasl
> Given the recent discussions:
>
> Should we move the current nmh project to maintenance-only
> mode, and start up a separate nmh2? It need not promise
> perfect backward compatibility, I would think reason enough
> to start anew.
>
> And it could be written in C++ :-]
>
> David
Sounds like a
On Nov 19, 2010, at 5:00 PM, David Levine wrote:
> And it could be written in C++ :-]
You have a funny way of spelling `Python'. ;-)
*Chad
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
On Nov 19, 2010, at 2:28 PM, Peter Maydell wrote:
> Debian currently builds --with-cyrus-sasl=/usr/include
> which I think would correspond to just using --with-cyrus-sasl.
> And most distros ought to be able to cope with setting CPPFLAGS
> and LDFLAGS for the build.
I would expect most distros
Given the recent discussions:
Should we move the current nmh project to maintenance-only
mode, and start up a separate nmh2? It need not promise
perfect backward compatibility, I would think reason enough
to start anew.
And it could be written in C++ :-]
David
_
Ken Hornstein wrote:
>> Also there doesn't seem
>>to be anything in ChangeLog about this...
>
>Sigh. It was getting late, I had to go home ... I wanted to get
>that stuff out there. I'll do the ChangeLog later.
I'd care a lot less about ChangeLog if we had a vcs that let
us look at a sane change
>>While this isn't a big deal personally, I will hazard a guess that
>>this change is unacceptable to nearly every package distro. I don't
>>know that we care, but I'd further guess that they'll either add the
>>functionality back in or (more likely) not include these versions of
>>nmh.
>
>Debian
Chad Brown wrote:
>On Nov 19, 2010, at 12:22 PM, Ken Hornstein wrote:
>> Now you can no longer say --with-cyrus-sasl=[DIR]; you have
>> to say --with-cyrus-sasl and use CPPFLAGS/LDFLAGS to add any options you
>> need for getting SASL from an alternate location.
>
>While this isn't a big deal person
On Nov 19, 2010, at 12:22 PM, Ken Hornstein wrote:
>
> Now you can no longer say --with-cyrus-sasl=[DIR]; you have
> to say --with-cyrus-sasl and use CPPFLAGS/LDFLAGS to add any options you
> need for getting SASL from an alternate location.
While this isn't a big deal personally, I will hazard
I had some time, so I took a look at the autoconf code that nmh uses.
Yikes ... okay, we don't do a great job here. Actually, that is being kind ...
we really do a TERRIBLE job with autoconf, don't we? I had forgotten how
bad it is. We could probably eliminate 80-90% of the autoconf tests we
cu
13 matches
Mail list logo
