In what appears to be fairly recent behaviour, when one selects "reply to all recipients", the recipients on the Cc list are *not* included as recipients on the reply. $ rpm -q alpine alpine-2.00-4.fc11.x86_64 $
Yeah, I see this too. Can you report to upstream alpine-info?
Adding a report from Robert here which seems to verify that this behavior is not due to funky mailing list headers. -- i have an old email account that still works -- rpjday. if i email myself at crashcourse and CC myself at mindspring, i'll get the email at crashcourse and, correctly, the mindspring account will be on the CC list. when i reply to *all*, nothing is placed on the CC list.
With respect to reporting this upstream to the alpine-info mailing list, is it not sufficient to report apparent Fedora-packaged software issues here? To post this on the a-i ML, one has to subscribe to that list first, and I'm not really keen on a bug-reporting protocol which requires one to submit something to bugzilla, *and* to have to report it again elsewhere.
It's fine to just report it here since I can easily reproduce it. We're all volunteers so I usually let people know that upstream has the best bet at fixing the bug. Reporting it here is fine, but my personal m.o. is to report any bugs I find upstream first and only use Bugzilla for issues with packaging or Fedora-specific problems. I understand the mailing list subscription angle, too, though. It's definitely not required. I'll probably find time to report it on alpine-info myself in the next week or two, and then I'll update alpine to the latest after it's fixed (unless it turns out to be some weird configuration issue that both of us have).
According to this page: http://www.washington.edu/alpine/alpine-info/subscribing.html subscription to the mailing list *is* required to post to it; otherwise, I would have posted.
Sorry, my fault for the confusing writing. Alpine-info requires subscribing to post to the list. You are not required to do so, I'll take care of that now that you've brought it to my attention. Thanks!
Actually, can you clarify what you're seeing; this may be expected behaviour. If I email from joshuadf to:joshuadf and cc:joshuadf, then "Reply to all recipients?" it only has "to: joshuadf". However, that makes sense because it's from me. On the other hand, if I send from a separate email account to:joshuadf and cc:joshuadf and reply to that it works.
Here's a sample attempt at a "Reply to All". I configured alpine to add the mail header to the outgoing reply so, in the included text, you can see how many folks there were on the CC list. note, however, that the reply is going only to R. Dreier. that's simply incorrect. it should also be going to everyone on that CC list, no? To : Roland Dreier <rdreier> Cc : Attchmnt: Subject : Re: arch/x86/Kconfig selects invalid HAVE_READQ, HAVE_WRITEQ vars ----- Message Text ----- On Sun, 19 Apr 2009, Roland Dreier wrote: > Date: Sun, 19 Apr 2009 14:12:07 -0700 > From: Roland Dreier <rdreier> > To: Robert P. J. Day <rpjday> > Cc: Hitoshi Mitake <h.mitake>, Ingo Molnar <mingo>, > Linux Kernel Mailing List <linux-kernel.org> > Subject: Re: arch/x86/Kconfig selects invalid HAVE_READQ, HAVE_WRITEQ vars ... snip ... is there an alpine option that would control this? but even if there was, the fact that i *explicitly* select "reply to all" when replying should override whatever such an option would do.
Sorry, it works for me on Fedora 10. I had vger send me this email: http://lkml.org/lkml/2009/4/19/195 When I say Y to "Reply to all recipients?" I get the full CC list. It worked with my normal alpine config but just to be sure I used the default pinerc like this: mv .pinerc .sav-pinerc-20090421 alpine -pinerc .pinerc Then I changed only the inbox-path to my IMAP server. Can you try that?
OK, here's what I did. This is my current alpine version on F11 beta: $ rpm -q alpine alpine-2.00-4.fc11.x86_64 $ I moved my .pinerc out of the way, created a fresh one as you suggest above, then the only things I configured were: * user domain of "crashcourse.ca" * Include Header in Reply (for debugging purposes) * Signature at Bottom and that's it. and here's the result of replying to an arbitrary message in my mailbox: To : Sandeep K Sinha <sandeepksinha> Cc : Arun raj <arun.raj.linux> Attchmnt: Subject : Re: Is it possible to use file descriptor after main returns ----- Message Text ----- On Wed, 22 Apr 2009, Sandeep K Sinha wrote: > Date: Wed, 22 Apr 2009 16:59:17 +0530 > From: Sandeep K Sinha <sandeepksinha> > To: Arun raj <arun.raj.linux> > Cc: pradeep singh <pradeep.rautela>, kernelnewbies.org > Subject: Re: Is it possible to use file descriptor after main returns ... you can see from the included header that the kernelnewbies mailing list is on the CC list, but it is *not* included as a reply recipient. and i definitely specified a reply to *all*. What version of alpine are you using? And I'll regress my version of alpine to see if that changes things.
By the way, I have a fedora 9 system here with alpine-2.00-1.fc9.i386, and it works fine. are you sure you're testing this with alpine-2.00-4? because *that's* the version that's causing the (apparent) problem. And to reproduce what I'm seeing, don't use Fedora 10, use Fedora 11 beta.
confirmed, this is F-11 specific (so far).
I've confirmed that alpine works correctly on Ubuntu 9.04 which has almost all the same libraries as Fedora 11--but compiled with GCC-4.3 instead of GCC 4.4. Next step I guess is to build GCC-4.3 on Fedora 11 and try to figure out if its alpine or a library or what.
*** Bug 498677 has been marked as a duplicate of this bug. ***
Hmm. I just confirmed that if I build 'alpine' with CFLAGS="-g -fwrapv -fno-strict-aliasing" ./configure then it seems to work. I've not tested whether the -fwrapv/-fno-strict-aliasing have any effect, I just picked them because the kernel uses them, and gcc tends to do pretty insane things to some code without them. But it might simply be the lack of any optimization rather than those two flags. I'll see if I can dig any deeper.
Just plain CFLAGS=-g works too. But CFLAGS="-g -O" results in a broken alpine. And no, -fwrapv and -fno-strict-aliasing do not matter.
Looks like I can compile everything with -O2, _except_ one file: pith/reply.c If I compile pith/reply.c with -O2 it breaks. If I compile it without any optimizations, the end result works. But somebody should double-check that. Maybe I screwed up somewhere.
If I download the alpine src rpm, how can I rebuild the binary rpm without optimization? I modified the .spec file thusly: # make %{?_smp_mflags} EXTRACFLAGS="$RPM_OPT_FLAGS" make %{?_smp_mflags} as a quick and dirty test, but that didn't make any difference. Is there a better way to do that? You're obviously building straight from the tarball.
I've filed a gcc bug at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022 Robert--I don't think there is an easy way to rebuild the binary rpm without optimization, but Fedora alpine doesn't carry any patches. By the way, you can find links to the Fedora source packages, filed bugs, updates, etc, for any Fedora at the newish Package Database: https://admin.fedoraproject.org/pkgdb/packages/name/alpine Here is how to build alpine and reproduce this bug with gcc-4.4.0: # standard tools yum -y groupinstall "Development Tools" yum -y install fedora-packager # for alpine BuildRequires yum -y install aspell gettext inews krb5-devel ncurses-devel openldap-devel openssl-devel pam-devel mkdir alpinetest cd alpinetest svn checkout https://svn.cac.washington.edu/public/alpine/snapshots/ cd snapshots _sysconfdir=/etc/ touch imap/ip6 ./configure \ --enable-debug=no \ --without-tcl \ --with-c-client-target=lfd \ --with-passfile=.alpine.passfile \ --with-spellcheck-prog=aspell \ --with-system-pinerc=%{_sysconfdir}/pine.conf \ --with-system-fixed-pinerc=%{_sysconfdir}/pine.conf.fixed make alpine/alpine # try "Reply to all" and see bug cd pith rm -f reply.o && make CFLAGS=-O0 cd .. make alpine/alpine # try "Reply to all" and see it working
I've managed to reproduce this, seems only reply_seed function in pith/reply.c is problematic (adding __attribute__((__optimize__(0))) to it with -O1 -fno-inline -fno-inline-small-functions works just fine, changing that to (1) breaks. Trying to debug it...
Looks like a GCC bug, self-contained testcase: extern void abort (void); struct A { struct A *a; }; struct B { struct A *b; }; __attribute__((noinline)) struct A * foo (struct A *x) { asm volatile ("" : : "g" (x) : "memory"); return x; } __attribute__((noinline)) void bar (struct B *w, struct A *x, struct A *y, struct A *z) { struct A **c; c = &w->b; *c = foo (x); while (*c) c = &(*c)->a; *c = foo (y); while (*c) c = &(*c)->a; *c = foo (z); } struct B d; struct A e, f, g; int main (void) { f.a = &g; bar (&d, &e, &f, 0); if (d.b == 0 || d.b->a == 0 || d.b->a->a == 0 || d.b->a->a->a != 0) abort (); return 0; }
Will there be a new build (koji?) of alpine that we can test in the near future?
I suppose we could include jakub's gcc (no)optimize hack in the short-term. I'll get to work on that (holler if anyone has objections).
Here's a patched build: http://koji.fedoraproject.org/koji/taskinfo?taskID=1338469 Please test.
That appears to have solved that issue. Mind you, that's the *only* thing I tested so that's all I'm going to vouch for. But it's nice to have full replies back. Thanks.
Thanks Rex, I didn't think of that. I was getting worried about a patched gcc on the buildsys before F11 release!
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
alpine-2.00-5.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/alpine-2.00-5.fc11
Can we get this pushed for f11 update?
See comment #28 :)
I read that. My point was that it's still not *available* via a regular F11 update. In short, what's the holdup?
Updates for supported releases generally go through a testing phase, to make sure they don't introduce regressions, and that they actually fix the problems they are intended to fix. It would speed the process if testers would install the updates from the updates-testing repository, and visit http://admin.fedoraproject.org/updates/alpine-2.00-5.fc11 to vote on whether or not the update works correctly.
When/now updates get pushed is out of scope of this report, and not something maintainers have any control over. (ie, if you want more info, ask onlist)
Indeed, it looks like all I had to do is add a blank comment with "Works for me" and it moved to "pending". I'll close this bug.
Please don't (re-opening). I set bodhi to autoclose this when it gets pushed.
alpine-2.00-5.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
alpine-2.02-3.el4 has been submitted as an update for Fedora EPEL 4. https://admin.fedoraproject.org/updates/alpine-2.02-3.el4
alpine-2.02-3.el4 has been pushed to the Fedora EPEL 4 stable repository. If problems still persist, please make note of it in this bug report.