Re: css format changes

   From: Milan Zamazal <[email protected]>

   It happened again: New crm114 version doesn't read css files from
   previous crm114 versions correctly and causes trouble up to mail loss to
   Debian users.

   The problem is that one usually upgrades whole system from a
   distribution, without paying special attention to particular packages.
   After upgrading crm114 from 20080330 to 20090423, the newer crm114 reads
   the input (e.g. incoming mail) and the old css files, produces an *empty
   output* and exits with the *exit code 0* (at least on my computer and
   computers of some other Debian users).  

"Some?"  or "ALL"?  Big difference - and the difference may
well tell us where the problem really hides.

   So a typical user upgrades his
   computer and sooner or later he finds out crm114 is working erroneously
   and *all the incoming mail got silently lost in the meantime*.

   Would it be possible to fix this behavior?  Of course, the best solution
   from the user's point of view would be to make the css format stable.
   If this is not possible, crm114 should at least detect the
   incompatibility and exit with a non-zero code to prevent "successful"
   e-mail delivery.

   What do you think?

I'm looking at exactly this code and can't see the problem; we 
also tested this pretty well before issuing 20090423 and haven't seen it.

The file format hasn't changed- we went through particular care
to make sure that it did not change (although there are good
engineering reasons why, in the relatively near future, the
file formats WILL change.  But that code is not enabled yet
and it will be extremely well documented (it will also be the
debut of libcrm114- the callable library).

Is there something about Debian in particular that might be
the root of this evil?  It's not happening on Fedora nor on
Ubuntu that we can tell.

There is some good news though- if you have reaver enabled (by 
default, you do) then _all_ of your mail should be in the reaver
cache (this is another reason why we do NOT automagically install
a cron job to throw out the mail- until a user sees that it's working
and it's all stable, the email is there.

The very fact that it happens *AT ALL* really bothers me.

We have switched over to 64-bit developers machines, but that
should not cause the problem.  Indeed, the reverse- we've done
64-bit scrubbing, to make the 64-bit and 32-bit executions be
much more "in sync" (and they are, now discrepancies are within
the roundoff that we can explain..

Until we can sort this out, perhaps we should mark, in big 
red letters, that FILE FORMATS MAY CHANGE and that YOU MAY
NEED TO RETRAIN.

But, if you offered me a thousand dollars to tell you how this
happened, I would have to say "keep your money.  I don't know."

   - Bill Yerazunis

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get