Re: make install failure
Ok, i did 'make clean' and 'make install' after changing toplevel Makefile. Following errors are seen. Any clues ? 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:37, from auth.c:27: /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:37, from auth.c:27: /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:37, from auth.c:27: /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-p7[2]: *** [auth.o] Error 1 make-3.79.1-p7[2]: Leaving directory `/users/ruday/mutt-1.5.19/imap' make-3.79.1-p7[1]: *** [install-recursive] Error 1 make-3.79.1-p7[1]: Leaving directory `/users/ruday/mutt-1.5.19' make-3.79.1-p7: *** [install] Error 2 bash-2.05b$ bash-2.05b$ uname -a SunOS xx-view2 5.10 Generic_137111-06 sun4u sparc SUNW,Sun-Fire-V890 bash-2.05b$ On Thu, May 28, 2009 at 5:04 PM, Rocco Rutte pd...@gmx.net wrote: Hi, * Ravi Uday wrote: Its 4.0 Wow. $RCSfile: perl.c,v $$Revision: 4.0.1.8 $$Date: 1993/02/05 19:39:30 $ Patch level: 36 Your perl version is from 1993! Did you get that from a museum on tape? :-) Seriously, I don't think we should/need/do support something older than perl 5.003. With perl 4 I think your only options is to not build docs at all (edit top-level Makefile and remove 'doc' from the SUBDIRS and DIST_SUBDIRS lines) (or remove the perl call in doc/Makefile.am and live with partial documentation). Rocco
Re: Color problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tuesday, June 2 at 08:08 PM, quoth Ken Weingold: I hope I can explain this well. I just built mutt 1.5.19 after using 1.5.10 for quite a long time. 1.5.10 was using ncurses 5.2 and 1.5.19 was compiled using ncurses 5.6 (5.4 is also available). I have new mail in bold cyan. In 1.5.19, if I scroll the indicator up over the new emails, it unbolds them. Scrolling down over them will make them bold again. Any idea why this is happening? Do you mean that they're un-bolded while the indicator is highlighting them? Or do you mean that they're un-bolded only if the indicator is higher up on the list than they are and that when the indicator is lower in the list they become bolded again? If it's the former, then that's expected behavior (unfortunately) - the indicator bar isn't supposed to preserve *any* of the underlying index formatting. If the latter... that sounds like a bug. Try reporting it to mutt-dev and see if they have any ideas (my first guess would be to make sure it's linking against the version of ncurses that you think it is, e.g. with the ldd tool). ~Kyle - -- He that never changes his opinions, never corrects his mistakes, will never be wiser on the morrow than he is today. -- Tryon Edwards -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iQIcBAEBCAAGBQJKJpHRAAoJECuveozR/AWeXJgQAIxuF5cl4BptBX1001LSBDXH xrDsi5pfpXjbjpjJTUUgZyEYAkNhCuX3FJR43OKI9HP9E4TXW2Y0BHsZqnGRicXn 9c4L87SJMQdns4IXjm56J5YbnTJO5aLBi3VfVMkDx31VP1SYUbT504DiYEpAlzyv qjLIav7IcHXmnlWDhX/mj2bpWoP5mtdtE+aohFekBmxQTMQdyaR5ZmyI8h/QtAI3 2eJ+ceh180tkkESw0hyXQObDyFSh2h6dbDg3Qsniqy5I7nmLI6fnjMdyWaO2Np8V EI5Xjvx0ElQABrK7NLk3XR+wqWoJo3VFzMIpFYgul4v9hNvLtnrhwFvt+xatNRzF exd17N7ZCmSXHVgiOqipkEw1pkyb9cAanHKljiUQ5Zdy74DRdd7eVRmW5QS91t+E Mop4FYdKStqx3FpJ9JikvxkBufOi3QoGu917Q3NUYFpLRcYUQ4wt9c/h+VNJyFv+ 2YiR8/pVH1abN6Ch2bFqDyLhBLUot8FCQeFO+3Bz7IKAfoUqJRkkEuTgQFlxVjRp HLzf/LopND/ja8su7sZT/qJGUb2xLJtU9YP1ICuUPZ498z9jmnOZlhVTX2TKCvvl 15TPmPNLqMnCoJIAKMel7hGxY9nDVOaMml6aSJ8M1e0InpLqwts7U32TTkGmFkX1 W3E832wAi8d23qrU4VTJ =ma0x -END PGP SIGNATURE-
Re: make install failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wednesday, June 3 at 11:48 AM, quoth Ravi Uday: Ok, i did 'make clean' and 'make install' after changing toplevel Makefile. Following errors are seen. Any clues ? What I said before was that, according to google, these errors most likely indicate that your compiler (gcc) was originally configured and compiled on an older version of Solaris and that now that you've upgraded to a newer version, your compiler needs to be updated. These look like the exact same type of errors. If we assume for the moment that my advice was correct, you will continue to get these exact same errors until you update your compiler. What were you expecting to happen? Why were you expecting that? ~Kyle - -- Habits of thought persist through the centuries; and while a healthy brain may reject the doctrine it no longer believes, it will continue to feel the same sentiments formerly associated with that doctrine. -- Charlotte Perkins Gilman -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iQIcBAEBCAAGBQJKJpLDAAoJECuveozR/AWeTe0P+waFaGzowBfeR2ZMUhVKVrLa y1SlYVN6zBM2WbO17mq2mydrRT7jo6xSjpSWoWWM0QNT2/OzC44u3gaFlhANozCd Q4KJFAWN5FQRMdsRKHJlQomeCSFXE0f8MjxcLHQwgZU5Yfw/99gpL/CFsgk9Q7l1 /9H12QRAjl1n2eqwkpeQXqsDujMwYUJ/WBGZKRN15/EnYNRVR9rgQezH1XdbjN/Y +pL20a7tQPun5y6PMxSMvMdCEvoixOrQPMoxyyIiYWxwyjbwqdSHeU3MAGcZuvAu hdx8xVBF3f3n69xVfpb8Dps6CZMdlRuVBvxq8zIb+icXOtK7XD6qM4i5lEtXuegP zLZbQm8lwo9AoFWasXugcnrSh9WwmRh9+u0/C1EXfBJRDESMWRhGKGj83WOpPtHv HhUvGy/iqM8jGAFAYvpyS0CPRtziBB2v9SASd11TitFtswfRrijNFRP/lFrFrghT mCylsNxMw4+29MMRuZiWUdW9lYDQovUGUz+v417P4B8/B1YKK95bAM3E5vEd/8o5 +t/IH6pb9N6j/7/XdT2JYdBSLFKj5QGCy+Z3fDJdSgi68WCjsYsFrnythhp8+/En QspiVfpX3d5q9XZjnhpYdi7JENUmCUMNZneAfGT1crg1M6TwksVo1+j3VCBQCsm3 d56jY2iP3i8QxrKVoQI/ =C5Vj -END PGP SIGNATURE-
Re: How can I know if error happens when sending mail?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wednesday, June 3 at 05:20 PM, quoth Chengqi(Lars) Song: -code lars:~$ less .bin/msmtp-wrap #! /bin/bash msmtp $* if [ $? != 0 ] then gxmessage -wrap -fg red -bg black -default okay -center MSMTP: `tail -1 ~/.getmail/msmtp.log` fi -- I have a few minor suggestions. First, you probably don't want to use $*, but you probably want to use $@ instead, to preserve any arguments that might have spaces in them. Secondly, you don't have to use the $? variable, you can simply do this: #!/bin/bash if ! msmtp $@ ; then gxmessage -wrap -fg red -bg black -default okay -center \ MSMTP: `tail -1 ~/.getmail/msmtp.log` fi ~Kyle - -- No nation is permitted to live in ignorance with impunity. -- Thomas Jefferson -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iQIcBAEBCAAGBQJKJpNwAAoJECuveozR/AWe81oP/iZrn4ytub1+DXDtAhM93jLh ZWOEK2wNZpAOSscM+C3VjwlnQaQHPRCpYHBIVTZz8I0QUqZaKOYoNMMfCP03r5Ao DAb3tShzoFkB9mXYCepzPdrI6sbyozdj/gkRGDyZjEe9MzDVp6KJo3iuYJXbP4Q4 UNN533HoiI/mXLNxV2x5NVFmqCn8t+kwdV2WqM0Le0+IDgVpVom0F0ZNu2F8dKAY ncizdYFsBeVjgBuDVjzo6X6OD+uPGyYNZzW6UpiSL9iqEmkrJ40pa0fjC5uv3VvV SRyh8vfdkGXjMfF4iASnDUxXMBpdLCAVw1F3kn9nviudauyVbor2ythDY8armrNG v4wtb+TF5FhYaLUC95UpCdUSNX5Q+I+OUmq5UtyLHTx612vw0W9ZsfTci/7+du4t lHgujaHElAIy2SGMyp6PP1KoSrLp+znTVJBAvW5hv8pV/J0PfaRbV8UZwPNwdWHU Q3/TsKuApwxi9jPoWTAdyKyd1cYy7aJhpHvSrM2WELURuzQmwyNNpVFgKjB50iWz RPiFhknBZXvvrPWEmBAQS2XJbjmwGNIak4queg601UsIn+Trgot9gt94hbSFtdlU DlUWlzUazN7FA4MgYjdZUSd8DXwGUVUR428pFlSF1/ccYkblZp1Z2UXeA59KpdPc ZDFrJ/3aihKnkX7CBt4h =Q2YN -END PGP SIGNATURE-
Re: Color problem
On Wed, Jun 3, 2009, Kyle Wheeler wrote: On Tuesday, June 2 at 08:08 PM, quoth Ken Weingold: I hope I can explain this well. I just built mutt 1.5.19 after using 1.5.10 for quite a long time. 1.5.10 was using ncurses 5.2 and 1.5.19 was compiled using ncurses 5.6 (5.4 is also available). I have new mail in bold cyan. In 1.5.19, if I scroll the indicator up over the new emails, it unbolds them. Scrolling down over them will make them bold again. Any idea why this is happening? Do you mean that they're un-bolded while the indicator is highlighting them? Or do you mean that they're un-bolded only if the indicator is higher up on the list than they are and that when the indicator is lower in the list they become bolded again? It's actually when I move the indicator bar over them. If I jump straight to the top of the index, the boldness doesn't get affected. I do know it's compiling with the correct version of ncurses from 'mutt -v's output. Or could that not be correct? -Ken
Re: Color problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wednesday, June 3 at 11:18 AM, quoth Ken Weingold: Do you mean that they're un-bolded while the indicator is highlighting them? Or do you mean that they're un-bolded only if the indicator is higher up on the list than they are and that when the indicator is lower in the list they become bolded again? It's actually when I move the indicator bar over them. If I jump straight to the top of the index, the boldness doesn't get affected. I do know it's compiling with the correct version of ncurses from 'mutt -v's output. Or could that not be correct? What it's compiling against and what it's linking against could be two different things. Mutt gets the version number from the ncurses header files; but it's quite possible that those headers are mis-matched to the library that was actually used to link against. Assuming you don't know: compiling most large software (like mutt) is a two-step process. First, each source file (e.g. a .c file) is compiled into an object file (a .o file), then the object files are linked together along with any libraries that are needed to create an executable binary (the program itself). People who have multiple versions of any given library often get themselves into trouble by compiling with headers that don't match the libraries. For example, you could compile against version 2.6 and then link against 2.4. The program would think it was using 2.6, but since it was linked against 2.4, would run into weirdness. This isn't a problem for people who only ever have a single version of any given library available. ~Kyle - -- I would therefore like to posit that computing's central challenge, how not to make a mess of it, has not yet been met. -- Edsger Dijkstra -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iQIcBAEBCAAGBQJKJpacAAoJECuveozR/AWeBpIP/RNnEWwgmnfnk76xncqTWxsH v8r2bj9GhTPP2sOoCmTspjl2PuPBp36LmkMuowZeXu2otEUsSNNtinvAeo2GV8Ev +UWW3kdPr8fOnSLK6veeumpa/u1aVuYshGGxrq37sQnMEvssN72kkLPOHAd5CaxD uprnqdDeFyMzkkIsp5kd3bkrvM9Knr1TcaRFp1RAgCCQeEbQR1ZrPKZZqWjBdgub 7VQhKo6AUdvyfssiSlb2zPXSqcSXPgPpVzBbjEPRSC1IH3M3Xoh2Qf8czHNJxQ4P uhy0saW9fAkeKinUL2XpcWiNsCV3NOPIpE1Op2mRSz5GkptIHnteCRkhzU9Rw3Hb 6RvtJsvm5/yYwNZGDJ6EG+co/wo5+x1jt0KT1UkQLjooltOUPRLyETRKKc3dDtrx 6JbI/qncG9Ga9LoaeCbbTtSSiA95xp1EyvqsaApyGp7DjbQpcnpxlKvf8u78TcLD N/G7UuczfYjIpkZvdrLJ/PntW0/6Sgbf1uqD+1TYo4dNc78/YyDHcxVaZTSjTiCe yGxfyFpjgvcaHkK87N1w6i94YPohd4wQ9n+wy3fHASnjZu3hc/nvEb56Qes77ben 3CVh119/mtkA2a+S9+nciDhaX1ZwuBLsvDw6N8IA6RdQpTeNlOp0oFaFwjXuMrYu uX1jBBzHS0mC3QY6gSUm =sH9V -END PGP SIGNATURE-
Re: Color problem
On Wed, Jun 3, 2009, Kyle Wheeler wrote: What it's compiling against and what it's linking against could be two different things. Mutt gets the version number from the ncurses header files; but it's quite possible that those headers are mis-matched to the library that was actually used to link against. Assuming you don't know: compiling most large software (like mutt) is a two-step process. First, each source file (e.g. a .c file) is compiled into an object file (a .o file), then the object files are linked together along with any libraries that are needed to create an executable binary (the program itself). People who have multiple versions of any given library often get themselves into trouble by compiling with headers that don't match the libraries. For example, you could compile against version 2.6 and then link against 2.4. The program would think it was using 2.6, but since it was linked against 2.4, would run into weirdness. Ah, crap. :) This on panix.com servers. I used --with-curses=/usr/local/ncurses-5.6 They are really good, so I assume it is correct. There is also an ncurses-5.4 install under /usr/local. Either way, there is a patch I used for the last version of mutt I was using, 1.5.10. 5patch-1.5.1.nr.indicator_not_bright. This was to make any text under the indicator bar not bold. It still works, and interestintly enough, also fixes this issue. -Ken
Re: Color problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wednesday, June 3 at 11:36 AM, quoth Ken Weingold: Ah, crap. :) This on panix.com servers. I used --with-curses=/usr/local/ncurses-5.6 They are really good, so I assume it is correct. There is also an ncurses-5.4 install under /usr/local. That should do it, unless there are runtime LD_LIBRARY_PATH or LD_PRELOAD issues. Either way, there is a patch I used for the last version of mutt I was using, 1.5.10. 5patch-1.5.1.nr.indicator_not_bright. This was to make any text under the indicator bar not bold. It still works, and interestintly enough, also fixes this issue. Ahhh. You may want to post that patch to the mutt-dev team. If it really fixes a bug, they'll probably be interested in it. ~Kyle - -- I am certain there is too much certainty in the world. -- Michael Crichton, State of Fear -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iQIcBAEBCAAGBQJKJpvqAAoJECuveozR/AWe1k0P/igdfsAVa72pbu0JycLCIJS1 JnTDUtnlKPhMpQP7E4TCHvmm4N9MN6XpKTGHEJNsfqHB2Odgl1TVHZuBIYYA9G2K W/lqVZaqSkZBViXs6+gbNPFxzsJkQMG0R4Z6ZnfQDqPZP/7tQyGG0WKEAg420a1Q v+IZOeoeRpy5WjQTEGcaI301oDsF0njYECZxkuqG+QI17nu32Q0xdJU8E0JdH9Bm zOse7Jt9i2cJH8QtzEF8Y0Zsv/rCQeJFJ46OlwBdBVOLT3M1kbyS7aliO/gKmEMT i1H+QbyrvJNl89UVOkLWkF9m12gaQdP7z9dT3TbjTrakelcHQE6j9oem8LgBClxF Aenv8ZJqe0AfDTb0qoQEkEAoX/kMBdLoi72FLIsaeHIKOr9kkRw8V+FSLozje8lF 8atAp7HU02vrwFLvPcerCVbz9zgM2zVra/oODX2fcZTTtsIS5fe8valB0KLwb1OQ Oec/Z5A+IXun/+eYyx9g6YeAhlqS6FHEXuNg6c9JMIvfjSPKbSL+zBycFJb05/GI D6kiFrJZ/peBZHRBnnVF1O8r1zC+cjxCCpw2I6NnyGv4i49ARjT5vsfdtWm0EtvK LJ78ISROGVZloFa/pgvY9e5XG4K8RC4S5VINgQCdOHA9q/OlFwV5UQYc6Zw724zl bCLg87RLQ11KANGhgOKj =MpDJ -END PGP SIGNATURE-
Re: Color problem
On Wed, Jun 3, 2009, Kyle Wheeler wrote: Either way, there is a patch I used for the last version of mutt I was using, 1.5.10. 5patch-1.5.1.nr.indicator_not_bright. This was to make any text under the indicator bar not bold. It still works, and interestintly enough, also fixes this issue. Ahhh. You may want to post that patch to the mutt-dev team. If it really fixes a bug, they'll probably be interested in it. Will do. Thanks. -Ken
Re: How can I know if error happens when sending mail?
thanks, your suggestion is applied :) On Wed, 03 Jun 2009, Kyle Wheeler wrote: On Wednesday, June 3 at 05:20 PM, quoth Chengqi(Lars) Song: -code lars:~$ less .bin/msmtp-wrap #! /bin/bash msmtp $* if [ $? != 0 ] then gxmessage -wrap -fg red -bg black -default okay -center MSMTP: `tail -1 ~/.getmail/msmtp.log` fi -- I have a few minor suggestions. First, you probably don't want to use $*, but you probably want to use $@ instead, to preserve any arguments that might have spaces in them. Secondly, you don't have to use the $? variable, you can simply do this: #!/bin/bash if ! msmtp $@ ; then gxmessage -wrap -fg red -bg black -default okay -center \ MSMTP: `tail -1 ~/.getmail/msmtp.log` fi ~Kyle -- No nation is permitted to live in ignorance with impunity. -- Thomas Jefferson
Re: use current folder name as argument to abitrary command
On 31May2009 21:29, David J. Weller-Fahy dave-lists-mutt-us...@weller-fahy.com wrote: | * Cameron Simpson c...@zip.com.au [2009-05-31 01:41 -0500]: [...big snip...] | What if you change: |\\\` | into plain |\` | at the start and end? | | As you suggested, I changed the \\\` to \`, and voilĂ ! It works without | the macro! I can only plead tired-eye-rushing syndrome, as that's the | only way I should have missed trying all the possibilities instead of | skipping the one that worked. I suggested it deductively, but had the advantage of starting my debug from your example. | For the record the following folder-hooks work to execute a script and | pass the current folder name as the script's first command line | parameter. | #v+ | folder-hook +lists* 'set my_oldrecord=$record; set record=^; set my_folder=$record; set record=$my_oldrecord' | folder-hook . 'push :\`~/.mutt/listbox-to-email.pl\ $my_folder\`\enter\' | #v- Thank you, I've adopted exactly this incantation in my own muttrc: folder-hook . macro index '\$' \change-folder\$my_folderenter\ folder-hook . 'push :\`cs-mutt-per-folder\ $my_folder\`\enter\' | Also, I'll attach my little Perl script, as someone might find it handy. Wouldn't it be better to set from= always, and merely omit the subscribe command for non-lists? That way, if you switch _from_ a lists.* folder into a non-lists folder your from= will be repaired for non-list use. i.e. replace set wait_key with set from=your-core-address. I think that I rely on the alternates setting to control my fromness. (Except that I see there's a set from= in my config too. I shall have to check which one wins.) my own folder config script is here: http://www.cskk.ezoshosting.com/cs/css/bin/cs-mutt-per-folder It produces (pre the newline-semicolon conversion) output like this: set my_folder_delete='/home/cameron/mail/O/mutt' unhook save-hook; save-hook . $my_folder_delete This is because I map 'd' to: copy-message+hamentersave-messageenter Copy message to +ham, which is processed regularly to update bogofilter stats, then save-message into the folder's archive folder. O is a symlink to OLD/ where is this year. Anyway, many thanks for the code simplification! Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ Insisting on perfect safety is for people who don't have the balls to live in the real world. - Mary Shafer, NASA Ames Dryden