Bug 838359

Hmm, I cannot reproduce in Fedora 17. What TERM are you using and how are you connecting (i.e., I'm using ssh) and have "TERM=xterm-256color". Also I guess post your .pinerc (scrub username if you want) and what IMAP server you are using.

What I did:

rpm -q alpine
alpine-2.02-3.fc17.x86_64

In .pinerc I have Google Mail IMAP:
folder-collections="gmail" {imap.gmail.com:993/ssl/user=agmailaddr}[]

Run alpine, it prompts for gmail IMAP

HOST: yx-in-f108.1e100.net:993  USER: agmailaddr  ENTER PASSWORD:                                                                                                       

Ctrl-Z does nothing. If I then do a Ctrl-C it gives me the following:

[Alpine suspension not enabled - see help text]               

Then I looked at the tech notes:

less /usr/share/doc/alpine-2.02/tech-notes.txt 

I see there are two settings:
   _enable-suspend_
   _use-subshell-for-suspend_

I also ran 

alpine -z 

And was able to suspend at the IMAP prompt and come back.

Created attachment 597115 [details]
pinerc I use (stripped only from most folder names for privacy)

Probably the important part is the folder collection:


folder-collections=Mail/[],
        "Red Hat" {mail.corp.redhat.com/ssl/novalidate-cert/user=pwouters}[]

I do have enable-suspend set

Confirmed with your .pinerc on f17, thanks. Specific IMAP server does not seem to matter.


curl -O 'https://bugzilla.redhat.com/attachment.cgi?id=597115'

grep -v '^#' attachment.cgi\?id\=597115 | sed -e 's;paul;myuser;' | sed -e 's;"Red Hat.*;"gmail" {imap.gmail.com:993/ssl/user=agmailaddr}[];' > .pinerc 

alpine
# select IMAP, Ctrl-Z at IMAP password prompt
fg

Problem detected: "Received abort signal(sig=11)".
Alpine Exiting.


I'll report upstream to 
http://sourceforge.net/projects/re-alpine/

Reported:

https://sourceforge.net/tracker/?func=detail&aid=3542853&group_id=264924&atid=1128048


I'll track via the Re-alpine-bugs list.

Is there a good reason for pine to catch the segfaults itself, instead of letting it segfault normally so our regular reporting functionality takes it on and we get easier ways to log these into bugzilla with more information from the backtrace?

My preference would be to not have it catch the segfault with a user friendly message.

That's a good question. I'm assuming it goes back to alpine/pine's history as something that was often installed on timeshare systems and the ops did not want lots of core files littering the filesystem. Could also have to do with support for lots of platforms. At this point I would guess it could be taken out, or disabled for Linux at least. Patches accepted. :)

Well, no one at Sourceforge has touched the bug so I guess we're on our own. :)
Thanks for the patch in 841025


I also loaded it in gdb, looks like it crashes due to update_option_screen getting called with a null "screen" which probably shouldn't happen. That's all the time I've got for now.


Setup with:


yum -y install @development-tools
yum -y install aspell gettext inews krb5-devel ncurses-devel openldap-devel openssl-devel pam-devel

_sysconfdir=/etc/
touch imap/ip6
./configure \
  --enable-debug=yes \
  --without-tcl \
  --with-c-client-target=lfd \
  --with-smtp-msa=/usr/sbin/sendmail \
  --with-npa=/usr/bin/inews \
  --with-passfile=.alpine.passfile \
  --with-simple-spellcheck=hunspell \
  --with-interactive-spellcheck=hunspell \
  --with-system-pinerc=%{_sysconfdir}/pine.conf \
  --with-system-fixed-pinerc=%{_sysconfdir}/pine.conf.fixed

cd alpine
gdb ./alpine

run
signal SIGCONT
backtrace

Program received signal SIGSEGV, Segmentation fault.
update_option_screen (ps=0xb55030, screen=0x0, cursor_pos=0x0) at confscroll.c:3046
warning: Source file is more recent than executable.
3046        if((ctmp = screen->top_line) != NULL)
(gdb) bt
#0  update_option_screen (ps=0xb55030, screen=0x0, cursor_pos=0x0) at confscroll.c:3046
#1  0x00000000005c616e in optionally_enter (utf8string=utf8string@entry=0x7fffffff6e70 "", y_base=<optimized out>,
    y_base@entry=-3, x_base=x_base@entry=0, utf8string_size=utf8string_size@entry=100,
    utf8prompt=utf8prompt@entry=0x7fffffff5dc0 "HOST: pb-in-f108.1e100.net:993  USER: agmailaddr  ENTER PASSWORD: ", escape_list=escape_list@entry=0x0, help=help@entry=0x0, flags=flags@entry=0x7fffffff5a6c) at termin.gen.c:923
#2  0x000000000045a551 in mm_login_work (mb=mb@entry=0x7fffffff6ac0,
    user=user@entry=0x7fffffff7270 "agmailaddr", pwd=pwd@entry=0x7fffffff6e70 "", trial=trial@entry=0,
    usethisprompt=usethisprompt@entry=0x0, altuserforcache=altuserforcache@entry=0x0) at imap.c:961
#3  0x000000000054b6bb in mm_login (mb=mb@entry=0x7fffffff6ac0, user=user@entry=0x7fffffff7270 "agmailaddr",
    pwd=pwd@entry=0x7fffffff6e70 "", trial=trial@entry=0) at imap.c:859
#4  0x000000000060827b in imap_login (stream=0xb71330, mb=0x7fffffff6ac0, pwd=0x7fffffff6e70 "",
    usr=0x7fffffff7270 "agmailaddr") at imap4r1.c:1203
#5  0x000000000060e152 in imap_open (stream=0xb71330) at imap4r1.c:913
#6  0x00000000005df71a in mail_open_work (d=0xa9c6c0, stream=0xb71330, stream@entry=0x0,
    name=0x438540 "H\213=\231\302q", name@entry=0x7fffffff8f70 "{imap.gmail.com:993/ssl/user=agmailaddr}x",
    options=options@entry=80) at mail.c:1338
#7  0x00000000005e58db in mail_open (stream=stream@entry=0x0,
    name=name@entry=0x7fffffff8f70 "{imap.gmail.com:993/ssl/user=agmailaddr}x", options=options@entry=80)
    at mail.c:1260
#8  0x00000000005a7a03 in pine_mail_open (stream=stream@entry=0x0,
    mailbox=mailbox@entry=0x7fffffff8f70 "{imap.gmail.com:993/ssl/user=agmailaddr}x", openflags=80,
    openflags@entry=201326672, retflags=retflags@entry=0x0) at stream.c:588
#9  0x00000000005aa576 in mail_cmd_stream (context=context@entry=0xb6f840, closeit=closeit@entry=0x7fffffff93cc)
    at stream.c:3355
#10 0x0000000000547f78 in build_folder_list (stream=0x7fffffffc078, context=context@entry=0xb6f840, pat=0xb6f7e0 "%",
    pat@entry=0x0, content=content@entry=0x0, flags=<optimized out>) at folder.c:964

Joshua et al.,

  This problem is fixed in Alpine 2.10, which can be obtained from

http://patches.freeiz.com/alpine/info/alpine.html

  Thank you.

-- 
Eduardo
http://patches.freeiz.com/alpine/

I confirmed this is fixed using a build of this alpine-2.10 version

I'm going to test this client version some more over the next few days, as it contains a lot more then just this fix.

Hi Eduardo,

Thanks so much! It appears the "Alpine 2.10" from your site the README file says it is licensed under ASL2.0, but the rcs update is from hubert@u and not you and you have not added your copyright notice to that file but you did add it to many other files. Can you therefore confirm you are licensing your contributions under ASL2.0 ? In the past you explicitly did not:
http://mailman2.u.washington.edu/pipermail/alpine-info/2011-April/004056.html

Also, I know this may not be your main concern but I see you're still including the conflicting non-commercial licensed file "pico/msmem.c" (BZ #888204).

To be clear: I am extremely grateful for your work and thank you!

Dear Joshua,

  I am starting to use git to maintain my work, this is mostly due to the crashing of my computer and losing pretty much everything in it, so the transition to a new rcs is being done slowly. If you have suggestions on what to change, I will be happy to read. It will be probably easy to release new versions of Alpine in the future than maintain patches, given the current state of affairs: I still have not sent my hard drive to be recovered, and doubt it will happen any time soon.

  In terms of licensing, Alpine 2.10 is licensed under the Apache License Version 2.0, my patches not included there are copyright me. I am transitioning from going from patches to releases of Alpine. I have at least 2 more releases, where more patches, and new features will go too. After that, probably only new features will go. Some current patches will stay as such.

  I understand your concern on removing code that is not clearly licensed. You might want to investigate if the person that actually wrote that code would be willing to license it. The code is not necessary for anything. I have never built nor run msmen.c, but it seems like a legacy from the time RAM was a rare commodity (as in "640K is sufficient for everyone").

  The message you refer to in your message talks about licensing patches to re-alpine. Nothing has changed in that regard, because the patches are still in my copyright, what changed was that I added some of those patches to the svn version of Alpine, and the resulting code was released under the Apache License 2.0 as version 2.10.

  I hope this clarifies the issue you are inquiring about. If not, just let me know.

-- 
Eduardo

Hi Eduardo,

Thanks for the reply. I should have mentioned, I attempted to contact Stephen Chung listed as author of the msmen.c file but both email addresses listed (from 1992) bounce, and it's a common enough name that I wasn't able to find anything recent for him.

In my opinion, it makes the most sense for your alpine 2.10 to become the upstream for Fedora/Red Hat but that file would need to be removed. 

Also, I've been added as an admin of the "re-alpine" SourceForge project so if you'd like to use the git there feel free:
http://sourceforge.net/apps/trac/sourceforge/wiki/Git
I'd be happy to make you admin on the project as well, as noted above development is not very active there, but SF does have a lot of downloads. 

Thank you,
Joshua

I tried to contact him as well at those email addresses, but also at linkedin,where I do believe I found him. But he has not responded to me yet.

Dear Paul and Joshua,

  Thank you for your messages. I did not know that an attempt had been made to contact him. In case it helps, there is a Stephen Chung in stackoverflow.com at

http://stackoverflow.com/users/650891/stephen-chung

It looks like it is him. I do not know if this is the same person that you attempted to contact earlier. I do agree that it would be better to have the permissions that are necessary for redistribution, etc.

  In regards to the specific file msmem.c, there is no harm in removing it, it does nothing. If you would like to remove it from the current release of Alpine 2.10, I would appreciate that. I will remove it from the next one for sure, unless I hear otherwise. Packaging Alpine is much harder now than it used to be without all the tools I use to package it - particularly due to the inclusion of patches, and creation/update of files that were done automatically in the past with the scripts I used to run, but if you give me a couple of days, I might be able to get an updated version up, without that file.

  In regards to git access, I am still struggling with that issue. I have my own local repository, which I'd like people to try and give feedback on. I have plans for a new release this year, but I am behind schedule, so I am not sure when will that happen. In any case, re-alpine is not an option at this time for me. My version of why I am not part of that effort is at

http://patches.freeiz.com/

  I am also thinking of moving development to github.com, but with so many projects using the word Alpine, it might not be the best idea.

  If I left anything unanswered please let me know.

-- 
Eduardo

Hi Eduardo,

Thanks for the reply. I hope that you are able to recover the environment you use for patching alpine. Regarding git, that seems like the best approach for the future, either at your website (as long as clone is available) or github. 

Lastly, just FYI if you are working on this anyway, a new BZ 924984 was just opened requesting support for ARM 64 (aarch64) and it came with an autoconf patch:
http://ausil.fedorapeople.org/aarch64/alpine/alpine-aarch64.patch

Thank you,
Joshua

Hi Eduardo or Paul,

Did you happen to hear back from Stephen Chung?

No I did not. The one I thought was the right person on linked in was someone else.

This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

2.10 fixed the problem for me, but this version is not yet in a fedora branch

joshua: any objection to the attached spec file for making new releases?

Created attachment 770603 [details]
updated spec file

Created attachment 770605 [details]
patch to fedora alpine repo to move to 2.10 and fix dates

joshua: if you want, I can push these changes. I just wanted to double check with you because of the sort-of-change of upstream

Go for it, no worries

alpine-2.10-4.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/alpine-2.10-4.fc19

alpine-2.10-4.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/alpine-2.10-4.fc18

alpine-2.10-4.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/alpine-2.10-4.el6

Package alpine-2.10-4.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing alpine-2.10-4.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-20421/alpine-2.10-4.fc19
then log in and leave karma (feedback).

alpine-2.10-4.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Package alpine-2.11-1.el6:
* should fix your issue,
* was pushed to the Fedora EPEL 6 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing alpine-2.11-1.el6'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12008/alpine-2.11-1.el6
then log in and leave karma (feedback).

alpine-2.10-4.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

alpine-2.11-1.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.