Re: Alpine mail client. Fresh install of 6.8. "Mail" works but Alpine problems
Stefan, A million thanks! Local host works! Too simple -- too logical! I would never have imagined that Alpine wouldn't have worked without that. Going to my mounted backup drive Look at how long I haven't needed to change one of the shell configuration files! ...: - pwd /home/... cd oldq3/ ls -l .cshrc -rw--- 1 ... ... 2707 Sep 23 2002 .cshrc -- Of course I regularly change certain minor features in pine/Alpine's .pinerc so last change was earlier this month. I am sure I never changed the smpt-server configuration, however. [not showing the .pinerc file date here since it changes often] Extract from old .pinerc -- smtp-server was always left blank up till now... --- # List of SMTP servers for sending mail. If blank: Unix Pine uses sendmail. smtp-server= # NNTP server for posting news. Also sets news-collections for news reading. nntp-server= Now going into the newly installed Alpine mail client Setup/Configure menu -- SMTP Server (for sending) = NNTP Server (for news)= I NOTE THAT FIRST USE AFTER NEW INSTALL, if there is no .pinerc file yet, it immediately tries to send a message back to the maintainers at U. of Washington, and obviously expects that to work, but instead, it immediately hangs. That probably means that something in how OpenBSD is configured these days, doesn't allow for that. But maybe it should, or rather, a small change in the patches for the Alpine port configuration, for OpenBSD, could allow for it to immediately send from the box where Alpine was just newly installed. Looking directly into the new .pinerc file: Extract follows: # List of SMTP servers for sending mail. If blank: Unix Alpine uses sendmail. smtp-server= # NNTP server for posting news. Also sets news-collections for news reading. nntp-server= /Extract i.e. same as ever Now after using the Setup/Configure menu in the latest version from 6.8 packages and setting the server to "localhost", as you suggested, the .pinerc looks like: Extract: # List of SMTP servers for sending mail. If blank: Unix Alpine uses sendmail. smtp-server=localhost # NNTP server for posting news. Also sets news-collections for news reading. nntp-server= /Extract AND THAT WORKS LIKE A CHARM! What's really curious is the statement in .pinerc that "If blank: Unix Alpine uses sendmail." Well to me that implies that it would use sendmail on the local host, so one wouldn't think that one would also have to specify it in the setup menu for first use. --- After one already had to deal with the initial "hang"! I note that the sendmail we now have is the pseudo Sendmail provided by the newer smpt/smptd system. I can't see that being the problem. Maybe some patch to Alpine was made for tighter OpenBSD security, or there is some additional system configuration I should have attended to these days. I'll put into my todo list to do a little more code digging, and look at the port if no one else gets to it. At the moment I have an incredible backlog of work and apologies to make for lost incoming emails after being down for a week, and also not replying even after incoming email was working and I had the awkward work-around of "Mail". I note that .calendar is not working for me. Wonder if it is a related kind of deeper problem in my system setup. Not critical though Most Alpine users (if any are still left), probably use an external mail server, and would have filled in something, so would never see this problem. Still would like to hear from any regular OpenBSD Alpine users. - Now to set up a new webserver too. And then maybe even do some crucial Year End company paperwork [Wish I had some time left for programming!] Stefan, again, thanks so much. Regards, Austin Hook Milk River, Canada On Sat, 23 Jan 2021, Stefan Hagen wrote: > Hi Austin, > > aus...@computershop.ca wrote: > > 2) Any reason why the new pseudo-Sendmail wouldn't handle Apline as > > well as the old one did? > > This mailing list is mostly for porting work and not for questions about > functionality or bugs that are not related to the porting process but > the software itself. > > That being said, I played around with alpine. You're right. If you leave > "smtp-server=" empty, sending an email gets stuck as you described. > > I've tried to set "smtp-server=" to localhost as well as to my > SMTP/SMTPs OpenSMTPd server. Those
Re: Alpine mail client. Fresh install of 6.8. "Mail" works but Alpine problems
Hi Austin, aus...@computershop.ca wrote: > 2) Any reason why the new pseudo-Sendmail wouldn't handle Apline as > well as the old one did? This mailing list is mostly for porting work and not for questions about functionality or bugs that are not related to the porting process but the software itself. That being said, I played around with alpine. You're right. If you leave "smtp-server=" empty, sending an email gets stuck as you described. I've tried to set "smtp-server=" to localhost as well as to my SMTP/SMTPs OpenSMTPd server. Those configurations are working fine and maybe you can use one of these? Why it gets stuck when falling back to the sendmail binary, I don't know. Using the sendmail binary manually is working here. The correct list to address this would be: https://opensmtpd.org/list.html Best Regards, Stefan
Re: alpine fails linking because of undefined reference to `RAND_egd'
On 2014/06/19 10:02, Sebastian Reitenbach wrote: On Wednesday, June 18, 2014 22:02 CEST, Stuart Henderson st...@openbsd.org wrote: On 2014/06/18 21:54, Sebastian Reitenbach wrote: On Wednesday, June 18, 2014 20:23 CEST, Stuart Henderson st...@openbsd.org wrote: On 2014/06/18 18:54, Sebastian Reitenbach wrote: Hi, not sure if this is known already, but this happens to me on i386: Check you don't have old libs around, especially make sure you've followed the kerberos removal on current.html. I did not upgrade, it happens on a fresh clean install. as it turned out, i have DEBUG= defined in my /etc/mk.conf, which is triggering the build failure. attached patch allows building alpine with DEBUG in mk.conf. Don't know if this is the most clever way, but looking at how other ports handle RAND_egd they just removed it. Also I'm unsure which of the many SUBPACKAGE to bump REVISION ;) It seems rather strange that setting DEBUG should trigger building code that uses RAND_egd ..
Re: alpine fails linking because of undefined reference to `RAND_egd'
On Thursday, June 19, 2014 10:28 CEST, Stuart Henderson st...@openbsd.org wrote: On 2014/06/19 10:02, Sebastian Reitenbach wrote: On Wednesday, June 18, 2014 22:02 CEST, Stuart Henderson st...@openbsd.org wrote: On 2014/06/18 21:54, Sebastian Reitenbach wrote: On Wednesday, June 18, 2014 20:23 CEST, Stuart Henderson st...@openbsd.org wrote: On 2014/06/18 18:54, Sebastian Reitenbach wrote: Hi, not sure if this is known already, but this happens to me on i386: Check you don't have old libs around, especially make sure you've followed the kerberos removal on current.html. I did not upgrade, it happens on a fresh clean install. as it turned out, i have DEBUG= defined in my /etc/mk.conf, which is triggering the build failure. attached patch allows building alpine with DEBUG in mk.conf. Don't know if this is the most clever way, but looking at how other ports handle RAND_egd they just removed it. Also I'm unsure which of the many SUBPACKAGE to bump REVISION ;) It seems rather strange that setting DEBUG should trigger building code that uses RAND_egd .. it indeed is, but I haven't seen any obvious #ifdef around it. There are some #ifdefs in that file, but nothing that immediately seems to relate to DEBUG Sebastian
Re: alpine fails linking because of undefined reference to `RAND_egd'
On 2014/06/18 18:54, Sebastian Reitenbach wrote: Hi, not sure if this is known already, but this happens to me on i386: Check you don't have old libs around, especially make sure you've followed the kerberos removal on current.html.
Re: alpine fails linking because of undefined reference to `RAND_egd'
On Wednesday, June 18, 2014 20:23 CEST, Stuart Henderson st...@openbsd.org wrote: On 2014/06/18 18:54, Sebastian Reitenbach wrote: Hi, not sure if this is known already, but this happens to me on i386: Check you don't have old libs around, especially make sure you've followed the kerberos removal on current.html. I did not upgrade, it happens on a fresh clean install. cheers, Sebastian
Re: re-alpine ports appears to be broken
On Sat, Jun 22, 2013 at 09:07:47PM -0700, Scott Vanderbilt wrote: Thanks very much for that. I'm not sure what I could have done differently, though. I grabbed my packages and the snapshot all within an hour or two earlier today from the same mirror. So I don't think it was a terribly unreasonable assumption on my part that they were mutually compatible. Is there any way to know that the snapshot and packages are out-of-sync so I can avoid any problems like this in the future? I did notice that they were two days apart, but didn't know whether that ipso facto meant there was a problem. I read the FAQ on this topic (5.1) and it is understandably vague on this point, but is it possible to determine when the next snapshot will be released? If tomorrow, I will wait. If not, then I will just go ahead and re-build the system from source. Look at krb5-config --libs gssapi output. If it shows heimntlm, krb5-config is outdated and might causing the build failure. cvs up in /usr/src/kerberosV/ and rebuild it from /usr/src/kerberosV/usr.bin/krb5-config. I had a similar issue with cyrus-sasl2 and that fixed it. Landry
re-alpine ports appears to be broken
Hello. I'm having trouble trying to build uw-imap on -current. There appears to be no maintainer for this port, thus my post here. I am running the latest available i386 snapshot: #sysctl -n kern.version OpenBSD 5.3-current (GENERIC.MP) #8: Thu Jun 20 09:51:38 MDT 2013 t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP I tried to install the package which is contemporary with this snapshot, but it is dated 17 June, and it fails to install. Here is the relevant output: #sudo pkg_add imap-uw-2.03p3v0.tgz Can't install imap-uw-2.03p3v0 because of libraries |library heimntlm.0.0 not found | not found anywhere |library hx509.0.0 not found | not found anywhere Direct dependencies for imap-uw-2.03p3v0 resolve to libiconv-1.14p0 gettext-0.18.2p2 Full dependency tree is libiconv-1.14p0 gettext-0.18.2p2 # Fair enough. So I try to build re-alpine from source. However, that fails also. I am using the current ports tree, from ports.tar.gz file dated 22-Jun-2013 03:07 #cd /usr/ports/mail/re-alpine #make === alpine-2.03p3 depends on: aspell-* - aspell-0.60.6.1p1 === alpine-2.03p3 depends on: gettext-=0.10.38 - gettext-0.18.2p2 === alpine-2.03p3 depends on: libtool-* - libtool-2.4.2 === alpine-2.03p3 depends on: bzip2-* - bzip2-1.0.6p0 === alpine-2.03p3 depends on: libiconv-* - libiconv-1.14p0 === Verifying specs: asn1 c crypto gssapi krb5 ncurses ssl com_err heimbase roken wind intl=5 iconv=6 asn1 c crypto gssapi krb5 ncurses ssl com_err heimbase roken wind intl=5 iconv=6 com_err crypto pthread ssl asn1 c crypto gssapi krb5 ncurses ssl com_err heimbase roken wind intl=5 iconv=6 com_err crypto ssl asn1 c crypto gssapi krb5 ncurses ssl com_err heimbase roken wind intl=5 iconv=6 com_err crypto ssl asn1 c crypto gssapi krb5 ncurses ssl com_err heimbase roken wind intl=5 iconv=6 pthread asn1 c crypto gssapi krb5 ncurses ssl com_err heimbase roken wind intl=5 iconv=6 pthread === found asn1.19.0 c.68.4 crypto.22.0 gssapi.6.0 krb5.19.0 ncurses.12.1 ssl.19.0 com_err.19.0 heimbase.0.0 roken.0.0 wind.0.0 intl.6.0 iconv.6.0 pthread.17.3 === Checking files for re-alpine-2.03 `/usr/ports/distfiles/re-alpine-2.03.tar.bz2' is up to date. (SHA256) re-alpine-2.03.tar.bz2: OK === Extracting for re-alpine-2.03 === Patching for re-alpine-2.03 === Configuring for re-alpine-2.03 Using /usr/ports/pobj/re-alpine-2.03/config.site (generated) configure: WARNING: unrecognized options: --disable-silent-rules configure: loading site script /usr/ports/pobj/re-alpine-2.03/config.site checking for a BSD-compatible install... /usr/bin/install -c -o root -g bin checking whether build environment is sane... yes checking for a thread-safe mkdir -p... mkdir -p checking for gawk... (cached) awk checking whether make sets $(MAKE)... (cached) yes checking whether to enable maintainer-specific portions of Makefiles... no checking build system type... i386-unknown-openbsd5.3 checking host system type... i386-unknown-openbsd5.3 configure: Configuring for alpine 2.03 (i386-unknown-openbsd5.3)) checking for gcc... cc checking whether the C compiler works... no configure: error: in `/usr/ports/pobj/re-alpine-2.03/re-alpine-2.03': configure: error: C compiler cannot create executables See `config.log' for more details. *** Error 77 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2603'/usr/ports/pobj/re-alpine-2.03/.configure_done': @for d in /usr/ports/pobj...) *** Error 1 in /usr/ports/mail/re-alpine (/usr/ports/infrastructure/mk/ bsd.port.mk:2368 'all') re-alpine # I'm not sure how to proceed. Any guidance would be greatly appreciated. Thank you.
Re: re-alpine ports appears to be broken
Can't install imap-uw-2.03p3v0 because of libraries |library heimntlm.0.0 not found | not found anywhere |library hx509.0.0 not found | not found anywhere Direct dependencies for imap-uw-2.03p3v0 resolve to libiconv-1.14p0 gettext-0.18.2p2 Full dependency tree is libiconv-1.14p0 gettext-0.18.2p2 # This shows that the package was compiled with old kerberos support. === Verifying specs: asn1 c crypto gssapi krb5 ncurses ssl com_err heimbase roken wind intl=5 iconv=6 asn1 c crypto gssapi krb5 ncurses ssl com_err heimbase roken wind intl=5 iconv=6 com_err crypto pthread ssl asn1 c crypto gssapi krb5 ncurses ssl com_err heimbase roken wind intl=5 iconv=6 com_err crypto ssl asn1 c crypto gssapi krb5 ncurses ssl com_err heimbase roken wind intl=5 iconv=6 com_err crypto ssl asn1 c crypto gssapi krb5 ncurses ssl com_err heimbase roken wind intl=5 iconv=6 pthread asn1 c crypto gssapi krb5 ncurses ssl com_err heimbase roken wind intl=5 iconv=6 pthread === found asn1.19.0 c.68.4 crypto.22.0 gssapi.6.0 krb5.19.0 ncurses.12.1 ssl.19.0 com_err.19.0 heimbase.0.0 roken.0.0 wind.0.0 intl.6.0 iconv.6.0 pthread.17.3 heimbase com_err etc... this shows that you are trying to use old userland and mixing it with current ports. solution is to wait for newer snaps or compile kernel/userland/xenocara and then try to compile the port yourself.
Re: re-alpine ports appears to be broken
Thanks very much for that. I'm not sure what I could have done differently, though. I grabbed my packages and the snapshot all within an hour or two earlier today from the same mirror. So I don't think it was a terribly unreasonable assumption on my part that they were mutually compatible. Is there any way to know that the snapshot and packages are out-of-sync so I can avoid any problems like this in the future? I did notice that they were two days apart, but didn't know whether that ipso facto meant there was a problem. I read the FAQ on this topic (5.1) and it is understandably vague on this point, but is it possible to determine when the next snapshot will be released? If tomorrow, I will wait. If not, then I will just go ahead and re-build the system from source. Thank you again for your response. On Sat, Jun 22, 2013 at 8:33 PM, Amit Kulkarni amitk...@gmail.com wrote: Can't install imap-uw-2.03p3v0 because of libraries |library heimntlm.0.0 not found | not found anywhere |library hx509.0.0 not found | not found anywhere Direct dependencies for imap-uw-2.03p3v0 resolve to libiconv-1.14p0 gettext-0.18.2p2 Full dependency tree is libiconv-1.14p0 gettext-0.18.2p2 # This shows that the package was compiled with old kerberos support. === Verifying specs: asn1 c crypto gssapi krb5 ncurses ssl com_err heimbase roken wind intl=5 iconv=6 asn1 c crypto gssapi krb5 ncurses ssl com_err heimbase roken wind intl=5 iconv=6 com_err crypto pthread ssl asn1 c crypto gssapi krb5 ncurses ssl com_err heimbase roken wind intl=5 iconv=6 com_err crypto ssl asn1 c crypto gssapi krb5 ncurses ssl com_err heimbase roken wind intl=5 iconv=6 com_err crypto ssl asn1 c crypto gssapi krb5 ncurses ssl com_err heimbase roken wind intl=5 iconv=6 pthread asn1 c crypto gssapi krb5 ncurses ssl com_err heimbase roken wind intl=5 iconv=6 pthread === found asn1.19.0 c.68.4 crypto.22.0 gssapi.6.0 krb5.19.0 ncurses.12.1 ssl.19.0 com_err.19.0 heimbase.0.0 roken.0.0 wind.0.0 intl.6.0 iconv.6.0 pthread.17.3 heimbase com_err etc... this shows that you are trying to use old userland and mixing it with current ports. solution is to wait for newer snaps or compile kernel/userland/xenocara and then try to compile the port yourself.
[new] re-alpine
Hi. This is a port of re-alpine that will supersed mail/alpine and mail/imap-uw. re-alpine is the continuation of the Alpine email client from University of Washington which development have been stopped. This port provides the following packages: alpine c-client imap-uw mailutil-uw pico pilot I'd appreciate tests and comments. Thanks. -- Antoine re-alpine.tgz Description: application/tar-gz
Re: alpine
On Mon, Mar 05, 2012 at 02:06:05PM -0800, Chris Cappuccio wrote: has anyone else noticed that alpine is very incompatible with rthreads? Nope. Nobody uses alpine. i sent diagnostics to guenther that were so bad, he didn't even reply. More seriously, when ? guenther has been fixing a huge amount of things concerning threads lately, some are still in transit. So, hey, first try again with a really current system. Then, try to figure out what's wrong. Simple test cases do help. Alpine is not a simple testcase. Also, how come guenther gets diagnostics and we don't ? I have no idea what your bug report looked like. Maybe he didn't reply because he had better bug reports to look at ?
Re: alpine
Marc Espie [es...@nerim.net] wrote: On Mon, Mar 05, 2012 at 02:06:05PM -0800, Chris Cappuccio wrote: has anyone else noticed that alpine is very incompatible with rthreads? Nope. Nobody uses alpine. I don't either, but some other folks do. i sent diagnostics to guenther that were so bad, he didn't even reply. More seriously, when ? guenther has been fixing a huge amount of things concerning threads lately, some are still in transit. I know. He is very thorough. And he usually replies very fast but the pathetic nature of my bug reports shut people down. So, hey, first try again with a really current system. Feb 27th kernel and library. I don't think anything significant has gone in since that time. Then, try to figure out what's wrong. Simple test cases do help. Alpine is not a simple testcase. Also, how come guenther gets diagnostics and we don't ? I have no idea what your bug report looked like. Maybe he didn't reply because he had better bug reports to look at ? Probably. Here's what I sent to him. Alpine alternates between crashing with sig11 when trying to send mail via SMTP, or failing to send mail through SMTP with a bogus SMTP error message (but not crashing). Sending e-mail always bails after the MAIL FROM in the SMTP session with a bogus 421 SMTP server error message (that the SMTP server didn't send) 13988 alpine GIO fd 8 wrote 34 bytes MAIL FROM:ch...@ref.nmedia.net\r 13988 alpine RET write 34/0x22 13988 alpine CALL read(0x9,0x204e2f000,0x1000) 13988 alpine RET read 0 13988 alpine CALL close(0x9) 13988 alpine PSIG SIGCHLD caught handler=0x4ba0a0 mask=0x0 13988 alpine RET close 0 13988 alpine CALL sigreturn(0x7f7c4ab0) 13988 alpine RET sigreturn JUSTRETURN 13988 alpine CALL close(0x8) 13988 alpine RET close 0 13988 alpine CALL wait4(0x6401,0x7f7c4e1c,0invalid0,0) 13988 alpine RET wait4 25601/0x6401 13988 alpine CALL sigaction(SIGINT,0x7f7c4e30,0x7f7c4e20) 13988 alpine RET sigaction 0 13988 alpine CALL sigaction(SIGHUP,0x7f7c4e30,0x7f7c4e20) 13988 alpine RET sigaction 0 13988 alpine CALL sigaction(SIGQUIT,0x7f7c4e30,0x7f7c4e20) 13988 alpine RET sigaction 0 13988 alpine CALL gettimeofday(0x7f7c91b0,0x7f7c91c0) 13988 alpine RET gettimeofday 0 13988 alpine CALL gettimeofday(0x7f7c91a0,0x7f7c91b0) 13988 alpine RET gettimeofday 0 13988 alpine CALL gettimeofday(0x7f7c9190,0x7f7c91a0) 13988 alpine RET gettimeofday 0 13988 alpine CALL kill(0xfb132,SIGTHR) 13988 alpine RET kill 0 28402 alpine PSIG SIGTHR caught handler=0x20cbd6de0 mask=0x808 28402 alpine RET nanosleep -1 errno 4 Interrupted system call Here's what happens when you try to send mail and alpine crashes: 13988 alpine GIO fd 1 wrote 81 bytes \^[[23;1H\^[[K\^[[24;1H\^[[K\^[[22;1H\^[[K\^[[7m\^[[22;27H[Sending mail | |]\^[[27m\^[[22;1H 13988 alpine RET write 81/0x51 13988 alpine CALL munmap(0x206518000,0x12000) 13988 alpine RET munmap 0 13988 alpine CALL mmap(0,0x12000,0x3PROT_READ|PROT_WRITE,0x1000MAP_ANON,0x,0) 13988 alpine RET mmap 8710569984/0x20730c000 13988 alpine CALL mprotect(0x20730c000,0x1000,0PROT_NONE) 13988 alpine RET mprotect 0 13988 alpine CALL __tfork(0x7f7c8e80) 13988 alpine RET __tfork 1007295/0xf5ebf 13988 alpine CALL gettimeofday(0x7f7c8d40,0x7f7c8d50) 13988 alpine RET gettimeofday 0 7295 alpine RET rfork 0 13988 alpine CALL gettimeofday(0x7f7c91b0,0x7f7c91c0) 7295 alpine CALL sigprocmask(SIG_BLOCK,0x808) 7295 alpine RET sigprocmask 0 13988 alpine RET gettimeofday 0 7295 alpine CALL nanosleep(0x20731dfb0,0) 13988 alpine CALL access(0x20c079f40,0x1X_OK) 13988 alpine NAMI /usr/sbin/sendmail 13988 alpine RET access 0 13988 alpine CALL pipe(0x7f7c81c0) 13988 alpine RET pipe 0 13988 alpine CALL pipe(0x7f7c81c0) 13988 alpine RET pipe 0 13988 alpine CALL vfork() 26036 alpine PSIG SIGTHR caught handler=0x20cbd6de0 mask=0x0 26036 alpine RET rfork 0 26036 alpine CALL sigreturn(0x7f7c7f50) 26036 alpine RET sigreturn JUSTRETURN 26036 alpine CALL sigprocmask(SIG_BLOCK,0x808) 26036 alpine RET sigprocmask 0 26036 alpine CALL sched_yield() 26036 alpine RET sched_yield 0 26036 alpine CALL sched_yield() 26036 alpine RET sched_yield 0 26036 alpine CALL sched_yield() 26036 alpine RET sched_yield 0 26036 alpine CALL sched_yield() 26036 alpine RET sched_yield 0 26036 alpine CALL sched_yield() 26036 alpine RET sched_yield 0 26036 alpine CALL sched_yield() 26036 alpine RET sched_yield 0 26036 alpine CALL sched_yield() 26036 alpine RET sched_yield 0 26036 alpine CALL sched_yield() 26036 alpine RET sched_yield 0 26036
Re: alpine check Do Not Send Flowed Text by default
On 2010/08/31 11:08, Antoine Jacoutot wrote: Hi. Following a chat with Daniel Dickman and after several questions in the past about how to send inline patches with alpine I'd like to enable the Do Not Send Flowed Text option by default. cool!!! Any ojections? none from me (I don't use alpine but this is total win for the mailing lists!).
Re: alpine check Do Not Send Flowed Text by default
On 2010/08/31 10:54, Stuart Henderson wrote: On 2010/08/31 11:08, Antoine Jacoutot wrote: Hi. Following a chat with Daniel Dickman and after several questions in the past about how to send inline patches with alpine I'd like to enable the Do Not Send Flowed Text option by default. cool!!! Any ojections? none from me (I don't use alpine but this is total win for the mailing lists!). ...and then we need to do the same for thunderbird :-)
Re: alpine check Do Not Send Flowed Text by default
On Tue, Aug 31, 2010 at 11:08:50AM +0200, Antoine Jacoutot wrote:
Hi.
Following a chat with Daniel Dickman and after several questions in the
past about how to send inline patches with alpine I'd like to enable the
Do Not Send Flowed Text option by default.
Any ojections?
I don't have an opinion on the option itself, but setting REVISION
without removing pX from PKGNAME-xxx looks wrong :)
Landry
Index: Makefile
===
RCS file: /cvs/ports/mail/alpine/Makefile,v
retrieving revision 1.11
diff -u -r1.11 Makefile
--- Makefile 8 Nov 2009 08:22:53 - 1.11
+++ Makefile 31 Aug 2010 08:38:39 -
@@ -18,6 +18,10 @@
PKGNAME-pico=pico-${PICO_V}p1
PKGNAME-pilot= pilot-${PILOT_V}p3
+REVISION-main= 1
+REVISION-pico= 1
+REVISION-pilot= 3
Re: alpine not installing
On Sun, Nov 29, 2009 at 11:00:07AM +0100, Sebastian Anding wrote: Hi Listmembers, i tried to install mail/alpine. But make install does not do anything. is it already installed? -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Re: alpine-1.00 core dump in autocompleting file name for msg export
On Mon, 19 May 2008, Jonathan Thornburg wrote: A gdb stack-trace of the latest core-dump (trying to export a message to the pathname msg/misc/nanaimo.people with Tab typed after the i shows this: (gdb) bt #0 0x0c2fe28d in kill () from /usr/lib/libc.so.43.0 #1 0x0c3206d4 in __stack_smash_handler (func=0x3c020e9e pico_fncomplete, damaged=233308416) at /usr/src/lib/libc/sys/stack_protector.c:89 Hmm stack overflow! I'll have a look as soon as I get a bit more time... Thanks for the report. -- Antoine
