Re: [Nmh-workers] Autoconf changes & new feature
> 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 about it [...] > So, I vote we move to git; objections? I still like CVS, but if an alternative is mandated, anything not spelled svn is fine ;-) Git seems to be a reasonable system from the limited use I've made of it. (And that's how I'm keeping my shadow posix tree right now.) --lyndon ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Autoconf changes & new feature
>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 paraphrase a line from "The Tao of Programming", "I do not wish to learn another version control system!". 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 about it (Peter, you say that the UI isn't wonderful, but it sounds like your objections are not that strong). So, I vote we move to git; objections? David Levine writes: >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. Is it April 1st already? :-) Were you thinking of writing a COMPLETELY NEW nmh from scratch? Or just saying, "Okay, we're no longer guaranteeing bug-compatibility with nmh1; your scripts may break"?. The latter doesn't sound bad to me (although I was actually thinking of making the new release be 2.0). The former ... well, if people WANT to do that, hey, more power to them. Just thinking about the work involved with that makes me tired. Unless my work is going to pay for that (unlikely), I simply don't have the free time to work on a large project like that. If people want to invest their time in that, then I say "go for it"; get togther, start coding, feel free to using this mailing list if you want. I'll contribute code to do SASL and TLS when you get to that point (assuming you want that code). But I'll still probably work on doing occasional maintenance on nmh1 until it looks like nmh2 (or nmh3, or whatever you call it) reaches critical mass. One suggestion, though: someone needs to be in charge. For example, right now we have 3 different suggestions on the language to write the hypothetical next-gen nmh in. Someone needs to make that decision. (My $0.02 - please, for the love of God, anything BUT C++). --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh2?
> 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 list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Autoconf changes & new feature
>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=/usr/include, the following things would happen: - SAL_INCLUDES would be defined with the value of -I/usr/include/include - SASL_LDFLAGS would be defined with the value of -L/usr/include/lib (or maybe it was SASL_LIBS). So unless the Debian folks actually patched configure.in, then I doubt it was doing what they thought it did. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh2?
> 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 good idea except for the C++ part. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh2?
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
Re: [Nmh-workers] Autoconf changes & new feature
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 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. > (I'd forgotten how lousy cvs was until I came back to > nmh; I don't suppose we could get consensus on moving > to a VCS with actual support for atomic commits and > other modern conveniences? :-)) Emacs moved from CVS to Bazaar for political reasons, and while it has settled down, it was pretty painful for a while. Also, most of the things that people wanted to do in bzr but couldn't easily make work seemed to be things that were easy and useful in git. Hope that helps, *Chad ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] nmh2?
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 __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Autoconf changes & new feature
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 changelog for the project :-) >And I don't think it will break the debian packaging, because now >the argument to --with-cyrus-sasl is silently ignored. Oh, OK; that makes sense. >it should still work fine. If it doesn't, let me know I've just tested, and configure fails with: checking sasl.h usability... no checking sasl.h presence... no checking for sasl.h... no configure: error: sasl.h not found because sasl.h is in /usr/include/sasl/sasl.h I think that's just a trivial error in your AC_CHECK_HEADER invocation, though. >>(I'd forgotten how lousy cvs was until I came back to >>nmh; I don't suppose we could get consensus on moving >>to a VCS with actual support for atomic commits and >>other modern conveniences? :-)) > >I kinda feel the same way. My vote is for git, I think git's UI is pretty foul but it has the advantage that it's rapidly becoming the de-facto DVCS standard. I could live with it or bzr. > but the REAL question is: where to put it? You have some reason for wanting to move away from savannah? (they support arch, bzr, git, mercurial and svn.) -- PMM ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Autoconf changes & new feature
>>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 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. Yeah, that's exactly what I was thinking (and really, why would setting CPPFLAGS/LDFLAGS be unacceptable for packaging distros? That's the way nearly every other autoconf package works). The problem we were running into was that if your Cyrus-SASL shared library was in a non-standard location, it only worked right for Solaris; everything else it broke. >But I do think it would be nicer if changes to remove existing >functionality and break back compatibility of build scripts >were discussed first and committed second (this one will break >my personal build-from-cvs setup, for instance, because I use >the debian packaging on cvs sources). 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. And I don't think it will break the debian packaging, because now the argument to --with-cyrus-sasl is silently ignored. So I think it should still work fine. If it doesn't, let me know and I'll gladly fix it. I could put a warning in there that arguments to --with-cyrus-sasl are now ignored if that would be helpful. >(I'd forgotten how lousy cvs was until I came back to >nmh; I don't suppose we could get consensus on moving >to a VCS with actual support for atomic commits and >other modern conveniences? :-)) I kinda feel the same way. My vote is for git, but the REAL question is: where to put it? --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Autoconf changes & new feature
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 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 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. But I do think it would be nicer if changes to remove existing functionality and break back compatibility of build scripts were discussed first and committed second (this one will break my personal build-from-cvs setup, for instance, because I use the debian packaging on cvs sources). Also there doesn't seem to be anything in ChangeLog about this... (I'd forgotten how lousy cvs was until I came back to nmh; I don't suppose we could get consensus on moving to a VCS with actual support for atomic commits and other modern conveniences? :-)) -- PMM ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Autoconf changes & new feature
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 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. I don't intend for this to sound like some sort of dire `or else' comment; I just thought that I'd point it out in case anyone cared. I've hand-built every version of nmh I've used for the last 12 years, at least. *Chad ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] Autoconf changes & new feature
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 currently do. In that vein ... I decided to massively simplify the code we use for selecting SASL libraries. 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. I thought about adding some new precious variables to autoconf just for SASL, but it turns out we don't use those for just files that we need, and that means there is no point to creating new variables. I had some special-case code for adding a different linker path for Solaris, but I decided to rip that out as well and have users have to add the right option to LDFLAGS. The only other option I see there would be to switch to libtool, and we did THAT then Lyndon Newberg's head with explode with such force that it would obliterate every bit of matter from here to Alpha Centauri :-). But seriously, even I hate libtool, so I'm not willing to go that route. I'm not really happy with the way our Makefiles are arranged, but that's enough of a job that I'd almost rather rewrite them using Automake, and I don't think there's enough support for that. I've mostly left them alone modulo some minor cleanups. Oh, I also added TLS support for the SMTP MTA. I tested it a bit, and it seems to work fine. SASL also works with it (but SASL encryption is turned off if TLS is in use), so if you need to use TLS plus authentication it should work fine. See --with-tls and the -tls flag to send/post. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
