Bug 459691

I've tried changing my configuration to use AUTH PLAIN and I've restarted Evolution (and checked that it really thinks it's supposed to use PLAIN). But it's _still_ in an endless loop trying CRAM-MD5 after I hit Send/Receive.

I managed to flush my Outbox by double-clicking to re-edit the first mail in it, then deleting that mail from the Outbox. After that, the other mails queued there went out OK.

When I looked at the compose window which opened when I double-clicked on that mail, it seems it was set to use my News account (which has an SMTP config which did still use CRAM-MD5; I'd forgotten about that and hadn't changed it). So part of the problem (or just _another_ problem) seems to be that Evolution uses the wrong account settings to send mail it finds in the Outbox at startup.

Having reminded myself how CRAM-MD5 works, it looks like the underlying fault is with Evolution. It's giving incorrect responses -- and it's the md5 part which is incorrect, so I can't see why.

Moved upstream [1], as I promised.

[1] http://bugzilla.gnome.org/show_bug.cgi?id=548863

Reopening here, because the CRAM-MD5 brokenness seems to be Fedora-specific. It seems that our glib2-devel-2.16.4-1.fc9.ppc package was shipped with this in glibconfig.h: #define G_BYTE_ORDER G_LITTLE_ENDIAN.

This seems to have happened because of an autohell change, where $ac_cv_c_bigendian ended up defined as 'universal' rather than 'yes', and this results in glib assuming little-endian:
http://www.mail-archive.com/autoconf-patches@gnu.org/msg02351.html

You can see this failure in the build log. The offending one is at http://kojipkgs.fedoraproject.org/packages/glib2/2.16.4/1.fc9/data/logs/ppc/build.log and says:

     checking whether byte ordering is bigendian... 
     universal

This is 'fixed' in glib2-2.16.5, and doesn't seem to have been broken in the previous F-9 package 2.16.3-7.fc9 either.

The broken glib2-2.16.4 was built on July 2nd, and the fixed glib2-2.16.5 was built on July 20th. Anything using G_BYTE_ORDER which was built between those times (and a little after, depending on when the fixed on got into the buildroot repos) may well be broken, and need rebuilding.

(The repeated retries on failure are GNOME bug 532472, for which a patch exists)

Hi David, I've a report in bug #456561, where reporter says the MD5 login is broken for him on a PPC even in Fedora 10. Are you able to checkout that, please? 

I looked to the build.log as you wrote above, on glib2-2.18.2-3.f10 and it seems correct, at least the answer for the "...is bigendian..." is 'yes', same as in the 2.16.5-1.fc9.

(changing platform to powerpc)

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  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 '9'.

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 9'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 9 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Marking this as a duplicate of the other.

*** This bug has been marked as a duplicate of bug 456561 ***