[Evolution-hackers] Mail corruption (was: Re: evolution releases and intltool brokeness)
On Fri, 2007-02-23 at 00:58 +0100, guenther wrote:
[...]
> Cc'ing Harish (tarball pushing) and Srini (release announcements), since
> I don't know who exactly does the packaging.
I know I did, and according to my Sent mail folder I am not totally
nuts.
However, the post that reached this list got the Cc snipped (even
checked the list archives). I do know for a fact that this has not been
the case for a post to another gnome.org mailing list a couple of hours
earlier.
Did someone configure this list to maliciously cripple mails?
I checked the headers, and there are a couple weirdnesses. a) The Cc
has been removed, b) The order of the headers are totally mixed and
c) The Date: header is different.
Yes, in fact. The Message-Id: is *identical*, but the Date: header is
off by one (granted, second). Sent mail folder stored on an IMAP server
(high speed local connection). Even though this might not seem to be
much, I believe this must not happen. Why is the Date: header generated
twice at all??
guenther
--
char *t="[EMAIL PROTECTED]";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution releases and intltool brokeness
On Wed, 2007-02-14 at 00:51 +0100, Gilles Dartiguelongue wrote:
> Hi list,
>
> while preparing ebuilds for gentoo gnome-experimental overlay, I came
> across a "fix" that was present since... who knows (years???).
>
> It's a simple call to intltoolize --force. What for ? To fix the sources
> released with a broken intltool. If you have generated the rules to
> compile translation with intltool 0.35.1 then if you have LINGUAS set to
> something else than what is available, the compilation breaks. intltool
> 0.35.[0234] handles that nicely.
>
> example: I have LINGUAS="fr en ja zh zh_CN", if ALL_LINGUAS only defines
> fr, zh_CN, I'm screwed. Please fix it for next release. Currently I'm
> sure gtkhtml-3.13.91 is affected but the fix is present on all evo
> related ebuild on gentoo so you might want to check these anyway.
*poke* What about this? Any response?
FWIW, this issue came up on IRC more than once the last weeks. This
definitely is an issue for Evo/e-d-s in addition to the above mentioned
GtkHTML. Also there recently has been a related discussion on d-d-l.
Basically, when packaging tarballs for the entire Evolution stack,
please make sure to use the latest tools available -- in this case
intltool 0.35.4, which fixes some brokeness WRT to *LINGUAS.
Cc'ing Harish (tarball pushing) and Srini (release announcements), since
I don't know who exactly does the packaging.
guenther
--
char *t="[EMAIL PROTECTED]";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] camel local provider and Bug 213072
On Thu, 2007-02-22 at 22:52 +, Seb James wrote:
> Hi Philip,
>
> I've not done any work on this recently, but I've not forgotten it; just
> been busy with other things.
>
> On Tue, 2007-01-16 at 05:44 +0100, Philip Van Hoof wrote:
> [snip]
> > If you want to implement a specialised version for "spool" folders, fill
> > in the function pointer like this:
>
> (in camel-spool-folder.c)
>
> > static void
> > camel_spool_folder_class_init(CamelSpoolFolderClass *klass)
> > {
> > CamelLocalFolderClass *lklass = (CamelLocalFolderClass *)klass;
> > + CamelFolderClass *camel_folder_class =
> > CAMEL_FOLDER_CLASS(camel_local_folder_class);
> >
> > parent_class = (CamelFolderClass *)camel_mbox_folder_get_type();
> >
> > lklass->create_summary = spool_create_summary;
> > lklass->lock = spool_lock;
> > lklass->unlock = spool_unlock;
> >
> > camel_folder_class->expunge = spool_expunge;
> >
> > }
> >
> > And implement it:
> >
> > + static void
> > + spool_expunge(CamelFolder *folder, CamelException *ex)
> > + {
> > + /* Call the method on super */
> > + parent_class->expunge (folder, ex);
> > + return;
> > + }
>
> Ok, I guess in this function, I'm going to have to get down and dirty
> with the spool file:
>
> Call spool_lock()
> Read it in, skipping expunged entries
> Write it out, sans expunged messages
> Call spool_unlock().
>
> Questions for anyone on the list:
> Is there a formalised way of getting the path to the spool file?
Got it:
CamelLocalFolder* localFolder;
int fd;
/* ..set up localFolder.. */
fd = g_open(localFolder->folder_path, O_LARGEFILE | O_WRONLY | O_BINARY, 0600);
> What are the camel functions for stepping through a mail file, looking
> at each message?
> Is there a "camel read message to data structure" kind of function?
I think the relevant functions are in camel_mime_parser.c
>
> Seb
>
> My original posting:
>
> > On Sun, 2007-01-14 at 21:00 +, Seb James wrote:
> > > Hi List,
> > >
> > > I'm looking at the local provider for camel, written by Michael Zucchi.
> > > It seems to be related to Bug 213072, which is now rather old, and which
> > > affects me.
> > >
> > > I'm trying to understand the code to begin with.
> > >
> > > I use a standard unix mail spool as my inbox, and I am wondering why it
> > > is that I can't expunge deleted messages from the spool. The spool just
> > > gets bigger and bigger, filling up with messages, flagged as deleted.
> > >
> > > So, question one to get me started is: What function in e-d-s carries
> > > out message expunging, as distinct from message deletion?
> > >
> > > regards,
> > >
> > > Seb James
>
>
> ___
> Evolution-hackers mailing list
> Evolution-hackers@gnome.org
> http://mail.gnome.org/mailman/listinfo/evolution-hackers
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] camel local provider and Bug 213072
Hi Philip,
I've not done any work on this recently, but I've not forgotten it; just
been busy with other things.
On Tue, 2007-01-16 at 05:44 +0100, Philip Van Hoof wrote:
[snip]
> If you want to implement a specialised version for "spool" folders, fill
> in the function pointer like this:
(in camel-spool-folder.c)
> static void
> camel_spool_folder_class_init(CamelSpoolFolderClass *klass)
> {
> CamelLocalFolderClass *lklass = (CamelLocalFolderClass *)klass;
> + CamelFolderClass *camel_folder_class =
> CAMEL_FOLDER_CLASS(camel_local_folder_class);
>
> parent_class = (CamelFolderClass *)camel_mbox_folder_get_type();
>
> lklass->create_summary = spool_create_summary;
> lklass->lock = spool_lock;
> lklass->unlock = spool_unlock;
>
> camel_folder_class->expunge = spool_expunge;
>
> }
>
> And implement it:
>
> + static void
> + spool_expunge(CamelFolder *folder, CamelException *ex)
> + {
> + /* Call the method on super */
> + parent_class->expunge (folder, ex);
> + return;
> + }
Ok, I guess in this function, I'm going to have to get down and dirty
with the spool file:
Call spool_lock()
Read it in, skipping expunged entries
Write it out, sans expunged messages
Call spool_unlock().
Questions for anyone on the list:
Is there a formalised way of getting the path to the spool file?
What are the camel functions for stepping through a mail file, looking
at each message?
Is there a "camel read message to data structure" kind of function?
Seb
My original posting:
> On Sun, 2007-01-14 at 21:00 +, Seb James wrote:
> > Hi List,
> >
> > I'm looking at the local provider for camel, written by Michael Zucchi.
> > It seems to be related to Bug 213072, which is now rather old, and which
> > affects me.
> >
> > I'm trying to understand the code to begin with.
> >
> > I use a standard unix mail spool as my inbox, and I am wondering why it
> > is that I can't expunge deleted messages from the spool. The spool just
> > gets bigger and bigger, filling up with messages, flagged as deleted.
> >
> > So, question one to get me started is: What function in e-d-s carries
> > out message expunging, as distinct from message deletion?
> >
> > regards,
> >
> > Seb James
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Why is GnomePrintContext still in GtkHtml?
Le jeudi 22 février 2007 à 13:46 +, Srinivasa Ragavan a écrit : > Hi Frederic, > > We did update the GtkHTML versions under the assumptions of API > extensions in 3.13.90. In 3.13.91 we have broken API/ABI and removed the > obsolete APIs but we havent bumped the versions accordingly. We will be > doing that in RC Monday. > > Thanks for pointing it out to us :) Thanks. Please add a big warning in the release announcement, since it breaks some applications like gnucash (which wasn't been ported to gtk-print). -- Frederic Crozat <[EMAIL PROTECTED]> Mandriva ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Why is GnomePrintContext still in GtkHtml?
Hi Frederic, We did update the GtkHTML versions under the assumptions of API extensions in 3.13.90. In 3.13.91 we have broken API/ABI and removed the obsolete APIs but we havent bumped the versions accordingly. We will be doing that in RC Monday. Thanks for pointing it out to us :) -Srini. On Thu, 2007-02-22 at 14:40 +0100, Frederic Crozat wrote: > Le mardi 23 janvier 2007 à 08:43 +0530, Srinivasa Ragavan a écrit : > > Matthew, > > > > It is an exposed interface, that is lying around after the GtkPrint > > migration. It should be removed in the next few updates. > > Well, this change is breaking API and ABI. It would be nice to change > gtkhtml major, since it isn't ABI compatible with previous version of > gtkhtml. > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Why is GnomePrintContext still in GtkHtml?
Le mardi 23 janvier 2007 à 08:43 +0530, Srinivasa Ragavan a écrit : > Matthew, > > It is an exposed interface, that is lying around after the GtkPrint > migration. It should be removed in the next few updates. Well, this change is breaking API and ABI. It would be nice to change gtkhtml major, since it isn't ABI compatible with previous version of gtkhtml. -- Frederic Crozat <[EMAIL PROTECTED]> Mandriva ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Where to put UI items for templates (Bug #127529)
On Wed, 2007-02-21 at 12:15 -0600, Matthew Martin wrote: > On 2/16/07, Sankar P <[EMAIL PROTECTED]> wrote: > > On Fri, 2007-01-26 at 16:59 -0600, Matthew Martin wrote: > > > I'm working on templates for evolution. I need to know where to put all > > > the UI items for templates. There would need to be a save template, > > > default new mail, and default reply items. I read some of the HIG and > > > stuck them in there so I could write the code. Here's a link to the > > > patches. http://mtt.martin.googlepages.com/ The first one is for > > > evolution, and the second is for evolution-data-server. > > > > > > I looked at the patches attached in the above url. The patches are not > > yet complete so I am not doing an in-line patch-analysis reply. Some of > > my comments are : > > > > - An account should be able to choose, what should be the default > > template that it has to use and it should be noted that NONE should also > > be an option here. > Where should this be added? Isn't this what the Default New Mail > thing is for? Do we even need the default new mail? How useful would > that be anyway? > > > > - You can add an option, "File->New from templates" which should list > > the templates and the user should be able to choose a template and start > > composing a mail. I will recommend getting a nod from Srini (CCed) for > > any usability/UI aspects regarding this, before you start coding. > > > > - You need to add a view-column, "Template name" that will be available > > for the Templates folder (only). All messages stored as templates > > should have a name associated to identify the message-template. It is > > far more usable to read, "Status Report", "Release Announcement Mail", > > "String Announcement Mail", "ABI Break announcement ;-)" etc., rather > > than opening every mail and seeing, "Is this what I want to send now ?" > > > Shouldn't this act just like drafts? Where are we going to get this > template name? Would this even be all that useful? It will be. On a longer run, we are planning to have pre-defined templates as well. A name for a template is always more useful than looking at the mail and knowing. Some people do not even enable Message-Preview. And think how useful a name for the template will be. Consider the scenario when a new employee joins an office and the moment he opens his Evolution, he can send things like Minutes-of-the-meeting, Status-report, Meeting-agenda, Leave-letters in the company-prescribed format. These standard templates will be pushed to his machine when the machine was prepared for him. You can ask for the name of the template once the user chooses, "Save as template". > > - You need to close the composer once an user chooses "Save > > Template" (as of now it is not doing and it keeps on creating new > > templates) . > Why should it do that? Saving a draft doesn't do this. Wouldn't this > just annoy the user? It shouldnt close. Your code creates a new copy of the template whenever save is pressed. That also shouldnt be the behavior. > > > > - Reopening a template and saving it again should not create a new > > template. As explained above. > > > > - Your patch misses mail.error.xml changes as a result none of the user > > choice-asking dialogs appear. > > > > - All mail operations like copy/move/DnD on templates folder should be > > disabled. (IMO, it is a lot more easier to implement a new tab under > > Composer-preferences than a new templates folder) > > > > - When there is a clash between account's default signature and the used > > template's signature, the template's signature should be given more > > priority. > > > > - The code to save a template should ensure teh uniqueness in naming > > etc. > > > > - There must be a way to create a normal new mail when the user has set > > a default-template. (May be a default Empty-mail template) > > > This isn't clear enough. How should this be done? Should the whole > default new mail idea be rethought? Should we just make this like a > draft that doesn't delete itself? What I am saying is: We may not want the same default new-mail template for all the accounts. It should be chooseable per account. My office account may need to have my company-logo, header, caption for all the mails that I send using it. Whereas, my personal account may want to default to a plain-text mail. And when the templates have a common storage that is not associated with any account, it will be useable across the accounts. Like the ANNOUNCE mail template that I described in my other mail. And to send a mail with in a defined template, just click on teh template, and choose new-mail-from-this-template from a contextual menu and/or file->new-mail-from-template which will list the templates. > > > > > ___ > > > Evolution-hackers mailing list > > > Evolution-hackers@gnome.org > > > http://mail.gnome.org/mailman/listinfo/evolution-hackers > > -- > > Sankar > > > > -- Sankar
Re: [Evolution-hackers] Where to put UI items for templates (Bug #127529)
On Thu, 2007-02-22 at 13:32 +0530, Srinivasa Ragavan wrote: > On Thu, 2007-02-22 at 00:38 -0700, Sankar P wrote: > > If all you need is just a non-deleting draft, you can use "Edit as new > > message". I have felt that this shouldn't be restricted to Sent-items > > alone as we allow configurable sent-folders. IIRC, there is a bug for > > this as well. > > > > Srini: Shall we make this available on all folders ? > > Im not for this feature against templates. I feel that templates should > be treated seperately. But I feel that this menu item should be enabled > for all folder, unless it breaks mail abstraction if any. I am not sure if my previous mail made it clear. I am not against implementation of templates. All I wanted to say was: When you need just a non-deleting draft you can use "Edit as new message" as one. It is in the same way how we suggested people to use vFolders before we came up with the account-level search. Implementation of templates is a separate task that should be carried out independent of the status of this. > > -Srini > > > -- Sankar ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Where to put UI items for templates (Bug #127529)
On Thu, 2007-02-22 at 00:38 -0700, Sankar P wrote: > If all you need is just a non-deleting draft, you can use "Edit as new > message". I have felt that this shouldn't be restricted to Sent-items > alone as we allow configurable sent-folders. IIRC, there is a bug for > this as well. > > Srini: Shall we make this available on all folders ? Im not for this feature against templates. I feel that templates should be treated seperately. But I feel that this menu item should be enabled for all folder, unless it breaks mail abstraction if any. -Srini > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
