make install failure
I am trying to install stable mutt version : mutt-1.4.2.3 I configured mutt on my sun m/c using configure --prefix= command properly. (configure --prefix=/users/xxx/mutt-1.4.2.3 --enable-pop --enable-imap --enable-locales-fix) There were no errors, but when i ran 'make install' I got these errors ? >> In file included from /sw/packages/gcc/c3.4.3-p3/sparc-sun-solaris2.8/lib/gcc/sparc-sun-solaris2.8/3.4.3/include/sys/signal.h:44, from /usr/include/signal.h:26, from ../mutt.h:34, from auth.c:23: /usr/include/sys/siginfo.h:259: error: parse error before "ctid_t" /usr/include/sys/siginfo.h:261: error: ISO C forbids data definition with no type or storage class /usr/include/sys/siginfo.h:292: error: parse error before '}' token /usr/include/sys/siginfo.h:292: error: ISO C forbids data definition with no type or storage class /usr/include/sys/siginfo.h:294: error: parse error before '}' token /usr/include/sys/siginfo.h:294: error: ISO C forbids data definition with no type or storage class /usr/include/sys/siginfo.h:390: error: parse error before "ctid_t" /usr/include/sys/siginfo.h:392: error: ISO C forbids data definition with no type or storage class /usr/include/sys/siginfo.h:398: error: conflicting types for '__fault' /usr/include/sys/siginfo.h:267: error: previous declaration of '__fault' was here /usr/include/sys/siginfo.h:404: error: conflicting types for '__file' /usr/include/sys/siginfo.h:273: error: previous declaration of '__file' was here /usr/include/sys/siginfo.h:420: error: conflicting types for '__prof' /usr/include/sys/siginfo.h:287: error: previous declaration of '__prof' was here /usr/include/sys/siginfo.h:424: error: conflicting types for '__rctl' /usr/include/sys/siginfo.h:291: error: previous declaration of '__rctl' was here /usr/include/sys/siginfo.h:426: error: parse error before '}' token /usr/include/sys/siginfo.h:426: error: ISO C forbids data definition with no type or storage class /usr/include/sys/siginfo.h:428: error: parse error before '}' token /usr/include/sys/siginfo.h:428: error: ISO C forbids data definition with no type or storage class /usr/include/sys/siginfo.h:432: error: parse error before "k_siginfo_t" /usr/include/sys/siginfo.h:437: error: parse error before '}' token /usr/include/sys/siginfo.h:437: error: ISO C forbids data definition with no type or storage class In file included from /usr/include/signal.h:26, from ../mutt.h:34, from auth.c:23: /sw/packages/gcc/c3.4.3-p3/sparc-sun-solaris2.8/lib/gcc/sparc-sun-solaris2.8/3.4.3/include/sys/signal.h:96: error: parse error before "siginfo_t" In file included from ../mutt.h:34, from auth.c:23: /usr/include/signal.h:111: error: parse error before "siginfo_t" /usr/include/signal.h:113: error: parse error before "siginfo_t" make-3.79.1-p3a[2]: *** [auth.o] Error 1 make-3.79.1-p3a[2]: Leaving directory `/users/ruday/mutt-1.4.2.3/imap' make-3.79.1-p3a[1]: *** [install-recursive] Error 1 make-3.79.1-p3a[1]: Leaving directory `/users/ruday/mutt-1.4.2.3' make-3.79.1-p3a: *** [install] Error 2 bash-2.05b$ >> any clues ?
preserve sig on fcc_clear OR: enforce sig on sending
Hoi, I want to store outgoing mails unencrypted on hard disk, no matter if I send them encrypted or not. Currently I use `fcc_clear=yes' for that, but it removes the signature also. The situation is: I frequently resend mails in slightly altered form. Therefore I use ESC-e from within the +sent folder. The problem is: As the messages are stored unencrypted and unsigned in +sent, the message is also set unsigned when using ESC-e. Unfortunately I sometimes forget to manually add the signature again. One solution would be fcc_clear only removing the encryption, but preserving the signature. Another solution would be to ensure all outgoing mail gets signed (unless explicitely changed). Actually, it would be enough if ESC-e does set the signature automatically. Yet, I found no way to configure a solution. Can you help me? meillo signature.asc Description: Digital signature
mutt-devel build patch fails for build, freebsd
HI. I am unable to port any MAKE options into mutt-build port on FreeBSD, and wondering if I am doing this correctly. I have put these into make.conf WITH_MUTT_IMAP_HEADER_CACHE=yes WITH_MUTT_CYRUS_SASL=yes WITH_MUTT_ASPELL=yes WITH_MUTT_SIDEBAR_PATCH=yes WITH_MUTT_DEBUG=yes Here is the result of the build Mutt 1.5.18 (2008-05-17) Copyright (C) 1996-2008 Michael R. Elkins and others. Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System: FreeBSD 7.1-RELEASE-p4 (i386) ncurses: ncurses 5.6.20080503 (compiled with 5.6) libiconv: 1.11 libidn: 1.8 (compiled with 1.8) Compile options: -DOMAIN -DEBUG -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE -USE_FCNTL +USE_FLOCK +USE_POP +USE_IMAP -USE_SMTP +USE_GSS +USE_SSL_OPENSSL -USE_SSL_GNUTLS -USE_SASL +HAVE_GETADDRINFO +HAVE_REGCOMP -USE_GNU_REGEX +COMPRESSED +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME -CRYPT_BACKEND_GPGME -EXACT_ADDRESS -SUN_ATTACHMENT +ENABLE_NLS -LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID -USE_HCACHE -ISPELL SENDMAIL="/usr/sbin/sendmail" MAILPATH="/var/mail" PKGDATADIR="/usr/local/share/mutt" SYSCONFDIR="/usr/local/etc" EXECSHELL="/bin/sh" -MIXMASTER To contact the developers, please mail to . To report a bug, please visit http://bugs.mutt.org/. vvv.quote patch-1.5.0.ats.date_conditional.1 dgc.deepif.1 vvv.initials rr.compressed -- Thanks, Jason
mutt-devel build issues, freebsd
HI. I am unable to port any MAKE options into mutt-build port on FreeBSD, and wondering if I am doing this correctly. I have put these into make.conf WITH_MUTT_IMAP_HEADER_CACHE=yes WITH_MUTT_CYRUS_SASL=yes WITH_MUTT_ASPELL=yes WITH_MUTT_SIDEBAR_PATCH=yes WITH_MUTT_DEBUG=yes Here is the result of the build Mutt 1.5.18 (2008-05-17) Copyright (C) 1996-2008 Michael R. Elkins and others. Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System: FreeBSD 7.1-RELEASE-p4 (i386) ncurses: ncurses 5.6.20080503 (compiled with 5.6) libiconv: 1.11 libidn: 1.8 (compiled with 1.8) Compile options: -DOMAIN -DEBUG -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE -USE_FCNTL +USE_FLOCK +USE_POP +USE_IMAP -USE_SMTP +USE_GSS +USE_SSL_OPENSSL -USE_SSL_GNUTLS -USE_SASL +HAVE_GETADDRINFO +HAVE_REGCOMP -USE_GNU_REGEX +COMPRESSED +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME -CRYPT_BACKEND_GPGME -EXACT_ADDRESS -SUN_ATTACHMENT +ENABLE_NLS -LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID -USE_HCACHE -ISPELL SENDMAIL="/usr/sbin/sendmail" MAILPATH="/var/mail" PKGDATADIR="/usr/local/share/mutt" SYSCONFDIR="/usr/local/etc" EXECSHELL="/bin/sh" -MIXMASTER To contact the developers, please mail to . To report a bug, please visit http://bugs.mutt.org/. vvv.quote patch-1.5.0.ats.date_conditional.1 dgc.deepif.1 vvv.initials rr.compressed -- Thanks, Jason
authenticated smtp problems
Hello, One of my email providers just migrated to a new email system (Zimbra). With just a tiny adjustment in my muttrc (change from imaps://old.domain.com to imaps://new.domain.com) I seem to be able to read mail just fine. I cannot send it in the way I'm supposed to. They require authenticating smtp with ssl, so I have smtp_url=smtps://u...@new.domain.com. I keep getting "connection refused". The debug report gives me this: Connection failed. errno: 61... Could not connect to new.domain.com (Connection refused). Connected to new.domain.com:465 on fd=-1 mutt_socket_close: Attempt to close closed connection. imap_access: found Sent in cache If I try to put port 587 into smtp_url, I get the following: SSL failed: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol Connected to new.domain.com:587 on fd=-1 mutt_socket_close: Attempt to close closed connection. For a while I was getting Error 6 in the debug report. I don't understand what's going on. Apple Mail can send mail with the new system just fine, using authenticating SSL smtp server, as can Thunderbird (in Mail.app, the box for Use SSL is checked, and next to "Authentication" it says "Password". I even tried reverting to msmtp, but couldn't get that to work at all. Msmtp would tell me that the server doesn't understand TLS, but if I have tls off and auth on in the msmtprc, mutt complains that the server doesn't understand authentication! I know it does, since Apple Mail does it and the university's new system instructions explicitly say to turn on authentication and ssl. Oddly I can send mail from mutt *unauthenticated*, using smtp://new.domain.com Mutt is getting hung up on securely using smtp. I would like to do it securely, not only because my provider says we have to, but because I'll bet a lot of money the server won't let me do it sans authentication when I'm on the road (which I haven't been able to test yet). I cannot tell if this is a bug in the new system, in mutt, or with my setup. I am on OSX 10.5.7, with mutt 1.5.19hg from 05/15/2009. I tried reverting to 1.5.19 with no change. The same stuff happens on 10.4.11. -gmn
mutt default mailer KDE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is it possible to set mutt to be used as the default MUA system wide in KDE? Or something that would need to be set on a per application basis? - -- Daryl Styrk Naples FL, USA -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkoUXg4ACgkQ6baBhW8CzrjjaQCbBrkKPyM3j0+S28Tazt0YVpjX T7oAn0eB5rdcUb2bWgRkLaHSjB7udKWM =XGGz -END PGP SIGNATURE-
Re: authenticated smtp problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wednesday, May 20 at 03:06 PM, quoth dv1...@wayne.edu: > One of my email providers just migrated to a new email system > (Zimbra). With just a tiny adjustment in my muttrc (change from > imaps://old.domain.com to imaps://new.domain.com) I seem to be > able to read mail just fine. Good! As would be expected. > They require authenticating smtp with ssl, There's multiple ways of doing that. Are they any more specific? Before we get into this, let me explain the basic options here. There are three different protocol-level variations on basic SMTP service: SMTP, SMTPS, and Submission. The first, plain old SMTP on port 25, is unencrypted. Some (many, these days) servers support the STARTTLS command, which allows the connection to be encrypted AFTER it has been established. The second, SMTPS, is encrypted from the very first packet. As SMTP is supposed to be on port 25, SMTPS is supposed to be on port 465. There is no unencrypted version of SMTPS; it's *always* encrypted. The third, Submission, is virtually identical to SMTP, except that you must authenticate yourself (in a manner identical to SMTP-AUTH) before you can submit email. It is ALSO unencrypted, and ALSO usually supports the STARTTLS command to begin encrypting the connection after it has been established. Because it is so similar, this is almost always handled by telling the sending application to use SMTP on an alternate port (namely, the Submission port, 587). Generally speaking, SMTP clients detect the availability of the STARTTLS command and opportunistically use it; that applies to both SMTP and Submission, since they're so similar. > so I have smtp_url=smtps://u...@new.domain.com. I keep getting > "connection refused". Right, because that tells mutt to use SMTPS, which uses port 465 (and it seems to be a rare email provider that supports SMTPS). It would appear that your service provider does not provide the SMTPS service. > Connection failed. errno: 61... Could not connect to > new.domain.com (Connection refused). > Connected to new.domain.com:465 on fd=-1 mutt_socket_close: Translation: mutt attempted to contact them on port 465 and could not even establish a connection. Further translation: they do not support SMTPS. > If I try to put port 587 into smtp_url, I get the following: Your alternative is to use the Submission protocol? ... let me guess, you told mutt to use SMTPS on the Submission port, rather than telling mutt to use SMTP on the Submission port. > SSL failed: error:140770FC:SSL > routines:SSL23_GET_SERVER_HELLO:unknown protocol > Connected to new.domain.com:587 on fd=-1 mutt_socket_close: > Attempt to close closed connection. Looks like I guessed right. Your mistake was to use this: set smtp_url=smtps://new.domain.com:587 That tells mutt to use SMTPS on port 587. Since that means mutt expects the very first packet to be encrypted, and the very first packet WASN'T encrypted, the "connection" failed. If you had done this: set smtp_url=smtp://new.domain:587 ...it probably would have worked. Your mistake is assuming that "smtps://" means encryption and that "smtp://" means no encryption. In reality, "smtps://" means the SMTPS protocol and "smtp://" means the SMTP (or Submission) protocol. Does that make sense? > I don't understand what's going on. Apple Mail can send mail > with the new system just fine, using authenticating SSL smtp > server, That's... descending into gibberish. But chances are Apple Mail knows that port 587 ought to be treated the same as port 25. > as can Thunderbird (in Mail.app, the box for Use SSL is checked, and > next to "Authentication" it says "Password". Since most people don't care about the difference between SMTPS and SMTP+STARTTLS, Apple uses the "Use SSL" option to mean both, with the specifics depending on the port specified. It's a user-friendliness thing, rather than a "here's how experts think about it" thing. Thunderbird is usually a bit more pedantic about this sort of thing, but I wouldn't be surprised if it works for a similar reason. Now, their "user-friendliness" means that they would be a bit harder to use if you wanted to do something like use the SMTPS protocol on an alternate port, or use SMTP on the SMTPS port, but since nobody wants to do that, they get away with hiding the details. Mutt, on the other hand, is very literal. > I even tried reverting to msmtp, but couldn't get that to work at > all. Msmtp would tell me that the server doesn't understand TLS, Interesting. Am I correct in assuming that msmtp is connecting to port 25? > but if I have tls off and auth on in the msmtprc, mutt complains > that the server doesn't understand authentication! Well, that's easy to explain: most intelligent servers don't advertise authentication unless you're in an encrypted connection. Thus, without TLS, the server will deny that it knows anything about
Re: mutt default mailer KDE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, May 20, 2009 at 10:07:05PM +0200, Baptiste Grenier wrote: > Hi, > > Le 20/05/09 à 21:48, Daryl Styrk téléscripta : > > Is it possible to set mutt to be used as the default MUA system wide in > > KDE? Or something that would need to be set on a per application basis? > > For now I am using this in kde 4: > Go in System Settings -> Default Applications -> Email client > > Check "Use a different email client" and this line: > mutt -s "%s" %t > > It sets the To: and the Subject: fields. > > If you point the mouse cursor over the text field, you will the list of > available variables that could be used in the command line, see the man > page of mutt to get the available mutt switches. > > Cheers, > Baptiste > > -- > \,,/_[-_-]_\,,/ Thanks, I'll try that. I had tried mutt %u shooting in the dark and inadvertently dropped two blank messages to debian-user. - -- Daryl Styrk Naples FL, USA -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkoUZpwACgkQ6baBhW8Czrh43QCeLnsqVD8Druw/W6YTcTOETYjV Y2EAn1y1fsGhD2qPQcsAYfoTthENO8wK =0lXg -END PGP SIGNATURE-
Re: mutt default mailer KDE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 For archive purposes... mutt - "%s" %t with the box checked to 'Run in terminal' does the trick. If you forget that box it will send out blank emails in a split second... - -- Daryl Styrk Naples FL, USA -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkoUaaYACgkQ6baBhW8Czrg1kgCfc0GDI2wDAnKVzHFn5qPpSUvi ipQAniTOd3Q47IwcHoB7i5VHHGwU7yKJ =g07u -END PGP SIGNATURE-
Re: authenticated smtp problems
> > They require authenticating smtp with ssl, > > There's multiple ways of doing that. Are they any more specific? No, unfortunately. > Before we get into this, let me explain the basic options here. There > are three different protocol-level variations on basic SMTP service: > SMTP, SMTPS, and Submission. The first, plain old SMTP on port 25, is > unencrypted. Some (many, these days) servers support the STARTTLS > command, which allows the connection to be encrypted AFTER it has been > established. The second, SMTPS, is encrypted from the very first > packet. As SMTP is supposed to be on port 25, SMTPS is supposed to be > on port 465. There is no unencrypted version of SMTPS; it's *always* > encrypted. The third, Submission, is virtually identical to SMTP, > except that you must authenticate yourself (in a manner identical to > SMTP-AUTH) before you can submit email. It is ALSO unencrypted, and > ALSO usually supports the STARTTLS command to begin encrypting the > connection after it has been established. Because it is so similar, > this is almost always handled by telling the sending application to > use SMTP on an alternate port (namely, the Submission port, 587). > > Generally speaking, SMTP clients detect the availability of the > STARTTLS command and opportunistically use it; that applies to both > SMTP and Submission, since they're so similar. Thanks, this is helpful. [snip] > Your alternative is to use the Submission protocol? I don't know what my alternatives are (or, didn't until you just explained the three flavors of SMTP-ing). > ... let me guess, you told mutt to use SMTPS on the Submission > port, rather than telling mutt to use SMTP on the Submission > port. Indeed I did tell mutt to do that (unknowingly). > > SSL failed: error:140770FC:SSL > > routines:SSL23_GET_SERVER_HELLO:unknown protocol > > Connected to new.domain.com:587 on fd=-1 mutt_socket_close: > > Attempt to close closed connection. > > Looks like I guessed right. Your mistake was to use this: > > set smtp_url=smtps://new.domain.com:587 > > That tells mutt to use SMTPS on port 587. Since that means mutt > expects the very first packet to be encrypted, and the very first > packet WASN'T encrypted, the "connection" failed. If you had done > this: > > set smtp_url=smtp://new.domain:587 > > ...it probably would have worked. Your mistake is assuming that > "smtps://" means encryption and that "smtp://" means no encryption. In > reality, "smtps://" means the SMTPS protocol and "smtp://" means the > SMTP (or Submission) protocol. > > Does that make sense? Yes, it does, thanks. I did in fact assume that "smtps" means "secure" and "smtp" means "non-secure". (Being brought up with GUI apps that have just one checkbox for "authenticate" or "secure" or "SSL" one can easily think this is an either-or scenario). [snip] > > I even tried reverting to msmtp, but couldn't get that to work at > > all. Msmtp would tell me that the server doesn't understand TLS, > > Interesting. Am I correct in assuming that msmtp is connecting to port > 25? I got that with both port 587 and whichever port msmtp uses by default. > > I cannot tell if this is a bug in the new system, in mutt, or with > > my setup. > > It's most likely a problem with your setup. To recap, try this: As expected :) > > set smtp_url=smtp://new.domain.com:587 This seems to work so far. Many, many, many thanks. > I'm assuming that you're handling the smtp username and password > elsewhere (e.g. via smtp_user); otherwise, you'll need to set that up > as well. smtp_user is not in the manual for 1.5.19hg, and mutt tells me "unknown variable" when I start mutt if I have an smtp_user in my muttrc. I had put it in the muttrc, before I even read your email, because something in the back of my mind was telling me that such a setting existed (probably it did but has been removed). I'd been doing stmp_url=u...@blah.blah to get the user in there. -gmn
Re: mutt-devel build issues, freebsd
On Wed, May 20, 2009 at 09:53:13AM -0700, Jason Helfman wrote:
> I am unable to port any MAKE options into mutt-build port on FreeBSD,
> and wondering if I am doing this correctly.
>
> I have put these into make.conf
>
> WITH_MUTT_IMAP_HEADER_CACHE=yes
> WITH_MUTT_CYRUS_SASL=yes
> WITH_MUTT_ASPELL=yes
> WITH_MUTT_SIDEBAR_PATCH=yes
> WITH_MUTT_DEBUG=yes
.if ${.CURDIR:M*/mail/mutt-devel}
WITH_MUTT_IMAP_HEADER_CACHE=yes
WITH_MUTT_CYRUS_SASL=yes
WITH_MUTT_ASPELL=yes
WITH_MUTT_SIDEBAR_PATCH=yes
WITH_MUTT_DEBUG=yes
WITH_MUTT_FOO=bar
.endif
% make -C /usr/ports/mail/mutt-devel -V WITH_MUTT_FOO
bar
--
George
Re: authenticated smtp problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wednesday, May 20 at 04:56 PM, quoth dv1...@wayne.edu: >> set smtp_url=smtp://new.domain.com:587 > >This seems to work so far. Many, many, many thanks. Score! :) >> I'm assuming that you're handling the smtp username and password >> elsewhere (e.g. via smtp_user); otherwise, you'll need to set that >> up as well. > >smtp_user is not in the manual for 1.5.19hg, and mutt tells me >"unknown variable" when I start mutt if I have an smtp_user in my >muttrc. I had put it in the muttrc, before I even read your >email, because something in the back of my mind was telling me >that such a setting existed (probably it did but has been >removed). I'd been doing stmp_url=u...@blah.blah to get the user in there. Huh, you're right, I didn't check, I just assumed it was similar to the imap settings (which have imap_login). I include the user in the smtp_url setting as well (but then, I've never really understood why mutt's imap settings are the way they are either, since you can include the user in the $folder/$spoolfile setting). ~Kyle - -- My definition of marriage: ... it resembles a pair of shears, so joined that they cannot be separated; often moving in opposite directions, yet always punishing anyone who comes between them. -- Sydney Smith -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iQIcBAEBCAAGBQJKFIbzAAoJECuveozR/AWe4s0QAKvet81nd7xPldqzS7Esn4yQ of+YX2th4KGUVpnCAWt8TIOH2B8ltAWghLbF8TWoc0LHTZgaGyTAw6sZf7K1yyT9 Yyym2qGPRmyF8CkfhjIUgalewIlIsY1TzzOkpkw9xSIxBDKxzgEpb081y0tBK7kD 0oH6km95yzFcolJ9NvIFp8iyB3T9SPdJ2pGMDl4nBrmYWWOfqEF5QGE0myb+0diY PJLdnN1c4d6l58FPOI0iyNXutY9cFC8S/07NztJBh6k/Y8wPfKUbknHl9rvZkp2t DzDBKeJ1GuDd/1CIx45KYjzeqXzsx0EpwuF6SYQc6uNWN62NpCJnsVuYOB0lbB9/ n7jOT62TPsp2Yv154GRn4SxiU6uQbFa44jH+feIufaVyELPF/A9sgcjJeFIn1EYC mTUXaXr5QvxIhNBDDD8bvBb8c9/yDPciDu4Ji8R2W7VkN/nNh6v9NviQ7ax3J3qN Nfs+73OSzzOUwfn/jfJFqpuYt8MbWdUcenfpEofPRIw4RxxA1+GiTCNb3JjzBwh9 ujUTg0mUPaFq8RXTYFGS9tcU1xEQ4ISsavLueKvIDQddHTTA+E7ns3vowCRCYl4h B0ZJpfwfZan93kBhFvHHGvSGZm14cHi4Fy/YEoK33+6KZifq2enWuv1RKIEWa2XF SOz4t0b4j1d2X+6vvmMW =IeY+ -END PGP SIGNATURE-
Re: mutt-devel build issues, freebsd
They all come back with "yes"
Not sure where to go from here.
-Jason
On Wed, May 20, 2009 at 02:11:26PM -0700, George Davidovich thus spake:
On Wed, May 20, 2009 at 09:53:13AM -0700, Jason Helfman wrote:
I am unable to port any MAKE options into mutt-build port on FreeBSD,
and wondering if I am doing this correctly.
I have put these into make.conf
WITH_MUTT_IMAP_HEADER_CACHE=yes
WITH_MUTT_CYRUS_SASL=yes
WITH_MUTT_ASPELL=yes
WITH_MUTT_SIDEBAR_PATCH=yes
WITH_MUTT_DEBUG=yes
.if ${.CURDIR:M*/mail/mutt-devel}
WITH_MUTT_IMAP_HEADER_CACHE=yes
WITH_MUTT_CYRUS_SASL=yes
WITH_MUTT_ASPELL=yes
WITH_MUTT_SIDEBAR_PATCH=yes
WITH_MUTT_DEBUG=yes
WITH_MUTT_FOO=bar
.endif
% make -C /usr/ports/mail/mutt-devel -V WITH_MUTT_FOO
bar
--
George
Re: authenticated smtp problems
>>> set smtp_url=smtp://new.domain.com:587 >> >> This seems to work so far. Many, many, many thanks. Here is a variation that's worked well for me set smtp_url=smtp://usern...@mail.example.com/ set ssl_starttls=yes This initiates a dialog on port 25, upgrades to TLS, and supplies my SMTP username. (Using port 587 would probably work too.) Steve pgpyBavD26n6g.pgp Description: PGP signature
Fwd: make install failure
Anybody care to respond ?? or any other aliases -- Forwarded message -- From: Ravi Uday Date: Wed, May 20, 2009 at 5:38 PM Subject: make install failure To: mutt-users@mutt.org I am trying to install stable mutt version : mutt-1.4.2.3 I configured mutt on my sun m/c using configure --prefix= command properly. (configure --prefix=/users/xxx/mutt-1.4.2.3 --enable-pop --enable-imap --enable-locales-fix) There were no errors, but when i ran 'make install' I got these errors ? >> In file included from /sw/packages/gcc/c3.4.3-p3/sparc-sun-solaris2.8/lib/gcc/sparc-sun-solaris2.8/3.4.3/include/sys/signal.h:44, from /usr/include/signal.h:26, from ../mutt.h:34, from auth.c:23: /usr/include/sys/siginfo.h:259: error: parse error before "ctid_t" /usr/include/sys/siginfo.h:261: error: ISO C forbids data definition with no type or storage class /usr/include/sys/siginfo.h:292: error: parse error before '}' token /usr/include/sys/siginfo.h:292: error: ISO C forbids data definition with no type or storage class /usr/include/sys/siginfo.h:294: error: parse error before '}' token /usr/include/sys/siginfo.h:294: error: ISO C forbids data definition with no type or storage class /usr/include/sys/siginfo.h:390: error: parse error before "ctid_t" /usr/include/sys/siginfo.h:392: error: ISO C forbids data definition with no type or storage class /usr/include/sys/siginfo.h:398: error: conflicting types for '__fault' /usr/include/sys/siginfo.h:267: error: previous declaration of '__fault' was here /usr/include/sys/siginfo.h:404: error: conflicting types for '__file' /usr/include/sys/siginfo.h:273: error: previous declaration of '__file' was here /usr/include/sys/siginfo.h:420: error: conflicting types for '__prof' /usr/include/sys/siginfo.h:287: error: previous declaration of '__prof' was here /usr/include/sys/siginfo.h:424: error: conflicting types for '__rctl' /usr/include/sys/siginfo.h:291: error: previous declaration of '__rctl' was here /usr/include/sys/siginfo.h:426: error: parse error before '}' token /usr/include/sys/siginfo.h:426: error: ISO C forbids data definition with no type or storage class /usr/include/sys/siginfo.h:428: error: parse error before '}' token /usr/include/sys/siginfo.h:428: error: ISO C forbids data definition with no type or storage class /usr/include/sys/siginfo.h:432: error: parse error before "k_siginfo_t" /usr/include/sys/siginfo.h:437: error: parse error before '}' token /usr/include/sys/siginfo.h:437: error: ISO C forbids data definition with no type or storage class In file included from /usr/include/signal.h:26, from ../mutt.h:34, from auth.c:23: /sw/packages/gcc/c3.4.3-p3/sparc-sun-solaris2.8/lib/gcc/sparc-sun-solaris2.8/3.4.3/include/sys/signal.h:96: error: parse error before "siginfo_t" In file included from ../mutt.h:34, from auth.c:23: /usr/include/signal.h:111: error: parse error before "siginfo_t" /usr/include/signal.h:113: error: parse error before "siginfo_t" make-3.79.1-p3a[2]: *** [auth.o] Error 1 make-3.79.1-p3a[2]: Leaving directory `/users/ruday/mutt-1.4.2.3/imap' make-3.79.1-p3a[1]: *** [install-recursive] Error 1 make-3.79.1-p3a[1]: Leaving directory `/users/ruday/mutt-1.4.2.3' make-3.79.1-p3a: *** [install] Error 2 bash-2.05b$ >> any clues ?
Re: mutt-devel build issues, freebsd
On Wed, May 20, 2009 at 03:53:06PM -0700, Jason Helfman wrote:
> On Wed, May 20, 2009 at 02:11:26PM -0700, George Davidovich thus spake:
> > On Wed, May 20, 2009 at 09:53:13AM -0700, Jason Helfman wrote:
> > > I am unable to port any MAKE options into mutt-build port on FreeBSD,
> > > and wondering if I am doing this correctly.
> > >
> > > I have put these into make.conf
> > >
> > > WITH_MUTT_IMAP_HEADER_CACHE=yes
> > > WITH_MUTT_CYRUS_SASL=yes
Sorry, missed that. I think you want "WITH_MUTT_CYRUS_SASL2=yes".
> > > WITH_MUTT_ASPELL=yes
> > > WITH_MUTT_SIDEBAR_PATCH=yes
> > > WITH_MUTT_DEBUG=yes
> >
> > .if ${.CURDIR:M*/mail/mutt-devel}
> > WITH_MUTT_IMAP_HEADER_CACHE=yes
> > WITH_MUTT_CYRUS_SASL=yes
> > WITH_MUTT_ASPELL=yes
> > WITH_MUTT_SIDEBAR_PATCH=yes
> > WITH_MUTT_DEBUG=yes
> > WITH_MUTT_FOO=bar
> > .endif
> >
> > % make -C /usr/ports/mail/mutt-devel -V WITH_MUTT_FOO
> > bar
>
> They all come back with "yes"
Which is what you want.
cd /usr/ports/mail/mutt-devel
make clean
make rmconfig
make
...
If you don't understand the above, read through ports(7). Note that
questions like these really should be posted to freebsd-questions.
--
George
