Re: [Evolution] Evolution-ews and VPN-connection
Hi Milan, thanks for your message. I'm "just" a normal user but maybe I can find the problem with your suggestions for debugging. But maybe the problem has another cause? When I start Evolution, I can send/receive mails without problems. If I do something else for a certain time and afterwards want to send a mail I get this error: "Source 'helge...@...' doesn't support prompt for credentials" In the dialog I can click "repeat" and the mail is sent directly. Should i try to find this error with EWS_DEBUG=2 or CAMEL_DEBUG=all ? Thanks again :-) Helge ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] yahoo OAuth2
On 1/14/20 05:02, Milan Crha via evolution-list wrote: On Mon, 2020-01-13 at 15:50 -0500, Eugene via evolution-list wrote: I just found out that yahoo mail required OAuth2 since long time ago Hi, it doesn't really 'require' it, it rather 'supports' it. Hi Milan, Yahoo rejected my IMAP password and only creating new account in Thunderbird with OAuth2 allowed me access my email. Investigation revealed that yahoo access control don't differ from google - the same "less secure applications" toggle and plain IMAP password rejection if IMAP client IP address changed. Please consider following Thunderbird and allowing yahoo OAuth2 to avoid sudden access denied messages and avoid a need to have "less secure applications" toggle enabled. Eugene. ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] CalDAV is readonly
On Tue, 2020-01-14 at 14:25 +0100, Krauß, Peter (SCC) via evolution-
list wrote:
> So basically it boiled down to
> e_webdav_session_extract_privilege_simple only returning a single
> privilege and not the whole set which I think was the bug. Maybe the
> for loop in e_webdav_session_current_user_privilege_set_cb was
> supposed to deal with this...?
Hi,
aha, I see. I understood from RFC 3744 [1] that the
element can contain only single node, not multiple, and the servers I
connect to conform to this expectation, but I didn't find any explicit
mention of it in the RFC (just briefly searching through it).
> I can send you a diff.
That would surely help, at least to know exactly which parts you
touched. Was it anything like the attached patch, please? Could you
give it a try, please? It works here, but it the unpatched code worked
here as well.
By the way, having a reference in a form of a bug report filled at [2]
is appreciated. Such changes do need references, places where to look
for 'what & why' and eventually report regressions with them. Would you
mind to file one, please?
Thanks and bye,
Milan
[1] https://tools.ietf.org/html/rfc3744
[2] https://gitlab.gnome.org/GNOME/evolution-data-server/issues/new
diff --git a/src/libedataserver/e-webdav-session.c b/src/libedataserver/e-webdav-session.c
index a25fe938d..afb8ef4d7 100644
--- a/src/libedataserver/e-webdav-session.c
+++ b/src/libedataserver/e-webdav-session.c
@@ -288,7 +288,7 @@ e_webdav_property_change_free (gpointer ptr)
* Describes one privilege entry. The @hint can be %E_WEBDAV_PRIVILEGE_HINT_UNKNOWN
* for privileges which are not known to the #EWebDAVSession. It's possible, because
* the servers can define their own privileges. The hint is also tried to pair with
- * known hnts when it's %E_WEBDAV_PRIVILEGE_HINT_UNKNOWN.
+ * known hints when it's %E_WEBDAV_PRIVILEGE_HINT_UNKNOWN.
*
* The @ns_uri and @name can be %NULL only if the @hint is one of the known
* privileges. Otherwise it's an error to pass either of the two as %NULL.
@@ -4097,32 +4097,28 @@ e_webdav_session_traverse_privilege_level (xmlXPathContextPtr xpath_ctx,
if (node->type == XML_ELEMENT_NODE &&
node->name && *(node->name) &&
node->ns && node->ns->href && *(node->ns->href)) {
- break;
+ GNode *child;
+ gchar *description;
+ EWebDAVPrivilegeKind kind = E_WEBDAV_PRIVILEGE_KIND_COMMON;
+ EWebDAVPrivilegeHint hint = E_WEBDAV_PRIVILEGE_HINT_UNKNOWN;
+ EWebDAVPrivilege *privilege;
+
+ if (e_xml_xpath_eval_exists (xpath_ctx, "%s/D:abstract", prefix))
+ kind = E_WEBDAV_PRIVILEGE_KIND_ABSTRACT;
+ else if (e_xml_xpath_eval_exists (xpath_ctx, "%s/D:aggregate", prefix))
+ kind = E_WEBDAV_PRIVILEGE_KIND_AGGREGATE;
+
+ description = e_xml_xpath_eval_as_string (xpath_ctx, "%s/D:description", prefix);
+ privilege = e_webdav_privilege_new ((const gchar *) node->ns->href, (const gchar *) node->name, description, kind, hint);
+ child = g_node_new (privilege);
+ g_node_append (parent, child);
+
+ g_free (description);
+
+ if (e_xml_xpath_eval_exists (xpath_ctx, "%s/D:supported-privilege", prefix))
+ e_webdav_session_traverse_privilege_level (xpath_ctx, prefix, child);
}
}
-
-if (node) {
- GNode *child;
- gchar *description;
- EWebDAVPrivilegeKind kind = E_WEBDAV_PRIVILEGE_KIND_COMMON;
- EWebDAVPrivilegeHint hint = E_WEBDAV_PRIVILEGE_HINT_UNKNOWN;
- EWebDAVPrivilege *privilege;
-
- if (e_xml_xpath_eval_exists (xpath_ctx, "%s/D:abstract", prefix))
- kind = E_WEBDAV_PRIVILEGE_KIND_ABSTRACT;
- else if (e_xml_xpath_eval_exists (xpath_ctx, "%s/D:aggregate", prefix))
- kind = E_WEBDAV_PRIVILEGE_KIND_AGGREGATE;
-
- description = e_xml_xpath_eval_as_string (xpath_ctx, "%s/D:description", prefix);
- privilege = e_webdav_privilege_new ((const gchar *) node->ns->href, (const gchar *) node->name, description, kind, hint);
- child = g_node_new (privilege);
- g_node_append (parent, child);
-
- g_free (description);
-
- if (e_xml_xpath_eval_exists (xpath_ctx, "%s/D:supported-privilege", prefix))
- e_webdav_session_traverse_privilege_level (xpath_ctx, prefix, child);
-}
}
if (xpath_obj_privilege)
@@ -4292,11 +4288,10 @@ e_webdav_session_get_supported_privilege_set_sync (EWebDAVSession *webdav,
return success;
}
-static EWebDAVPrivilege *
-e_webdav_session_extract_privilege_simple (xmlXPathObjectPtr xpath_obj_privilege)
+static void
+e_webdav_session_extract_privilege_simple (xmlXPathObjectPtr xpath_obj_privilege,
+ GSList **out_privileges)
{
- EWebDAVPrivilege *privilege = NULL;
-
if (xpath_obj_privilege &&
xpath_obj_privilege->type == XPATH_NODESET &&
xpath_obj_privilege->nodesetval &&
@@ -4310,17 +4305,16 @@ e_webdav_session_extract_privilege_simple (xmlXPathObjectPtr xpath_obj_privilege
if (node->type == XML_ELEMENT_NODE &&
Re: [Evolution] yahoo OAuth2
On Mon, 2020-01-13 at 15:50 -0500, Eugene via evolution-list wrote: > I just found out that yahoo mail required OAuth2 since long time ago Hi, it doesn't really 'require' it, it rather 'supports' it. > and while evolution happily supports OAuth2 for google and outlook > mail OAuth2 does not seem to be offered for yahoo in v3.34.2. > > Am I missing something? No, you are not missing anything. The last time I checked Yahoo! OAuth2 interface they stopped to offer the Mail scope, without which it's kind of useless (or better not that useful as it could be). My information is few years old, I do not know the current situation, but as they offered it, then stopped to offer it for some reason, I'd not be surprised if they still do not allow to use that scope for new OAuth2 applications. Bye, Milan ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] Unable to retrieve message
On Mon, 2020-01-13 at 15:09 -0800, Jonathan Ryshpan wrote: > Done as GNOME > evolution-data-server > Issues > #182 > Messages on local maildir can't be retrieved Hi, thanks. Just for easier access to archive readers: https://gitlab.gnome.org/GNOME/evolution-data-server/issues/182 Bye, Milan ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] Importing a folder from MH/claws
On Tue, 2020-01-14 at 11:23 +0100, Christophe ROCHET wrote: > Please unsubscribe me. Please unsubscribe yourself. See the bottom of any message: > To change your list options or unsubscribe, visit ... > https://mail.gnome.org/mailman/listinfo/evolution-list -- Andre Klapper | ak...@gmx.net https://blogs.gnome.org/aklapper/ ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] Importing a folder from MH/claws
On Mon, 2020-01-13 at 15:45 -0800, Jonathan Ryshpan wrote: > When I attempt to copy the ross folder to the maildir account top > level from either the maildir account or the MH account, the Copy and > Move functions are grayed out. Hi, it looks like a bug, especially when the GUI allows to create new folders when 'On This Computer' is selected. I see the same behavior also when selecting IMAP accounts as the destination, not only On This Computer. It's true that some account types do not allow creating folders directly at the top level, they allow creating only subfolders of existing folders (like of the Inbox), but neither the On This Computer, nor IMAP accounts, are part of that group. Bye, Milan ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] How to automatically obtain PGP keys for e-mail recipients? (key discovery)
To follow up on this issue: Since GnuPG version 2.2.19 (included in Debian Backports [1]) this issue is resolved [2]. Thank you Milan for guiding me through the details! [1]: https://backports.debian.org/ [2]: https://dev.gnupg.org/T4726#131143 Am Wednesday, den 23.10.2019, 08:19 +0200 schrieb David Hebbeker: > To follow up on this issue: The form of the e-mail address with the > angle brackets has been discussed on the gnupg-users mailing list > [1], > tested with different GnuPG versions and a bug report [2] has > beencreated. > > [1]: > https://lists.gnupg.org/pipermail/gnupg-users/2019-October/062932. > html > [2]: https://dev.gnupg.org/T4726 > ___ > evolution-list mailing list > evolution-list@gnome.org > To change your list options or unsubscribe, visit ... > https://mail.gnome.org/mailman/listinfo/evolution-list signature.asc Description: This is a digitally signed message part ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] Importing a folder from MH/claws
On Tue, 2020-01-14 at 11:23 +0100, Christophe ROCHET wrote: > Please unsubscribe me. Please read the instructions at the end of every mail on this list. poc ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] CalDAV is readonly
On Tue, 2020-01-14 at 07:43 +, Krauß, Peter (SCC) via evolution- list wrote: > I did indeed do several restarts (without success). Hi, just to be clear, I didn't mean restart of the whole machine, but restart of the calendar factory only, that is, of the evolution-calendar-factory process. You even do not need to kill the process to be restarted, just close evolution, open terminal and execute there: $ /usr/libexec/evolution-calendar-factory -w then wait for few seconds and only then start Evolution. Though I think you captured the log from the initial email in a very similar way and it still did not work, thus this won't work as well. Maybe you can run DBus monitor and search what it passed around. You might focus on "writable" and "Writable" (quotes for clarity only) signals/properties. The command is: $ dbus-monitor then I see for example this after I open a calendar which had not been opened yet: > signal time=1578997003.522247 sender=:1.181 -> destination=(null > destination) serial=878 > path=/org/gnome/evolution/dataserver/Subprocess/6081/25; > interface=org.freedesktop.DBus.Properties; member=PropertiesChanged > string "org.gnome.evolution.dataserver.Calendar" > array [ > dict entry( > string "Writable" > variant boolean true > ) > ] > array [ > ] followed by a method invocation response: > method return time=1578997003.522745 sender=:1.181 -> destination=:1.226 > serial=879 reply_serial=42 > array [ > string "alarm-email-address" > string "''" > string "cache-dir" > . > string "writable" > string "true" > ] this is how the backends notify the clients about their state, one of them being writability. It's hard to recognize which calendar the response belongs to, that why I'd try on one, which is not opened yet. Note the dbus-monitor output will be very chatty, quite many things sends something over D-Bus all the time, thus expect interleaved output. Bye, Milan ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] Importing a folder from MH/claws
Please unsubscribe me. Télécharger BlueMail pour Android Le 14 janv. 2020 à 11:14, à 11:14, Milan Crha via evolution-list a écrit: >On Mon, 2020-01-13 at 15:45 -0800, Jonathan Ryshpan wrote: >> When I attempt to copy the ross folder to the maildir account top >> level from either the maildir account or the MH account, the Copy and >> Move functions are grayed out. > > Hi, >it looks like a bug, especially when the GUI allows to create new >folders when 'On This Computer' is selected. I see the same behavior >also when selecting IMAP accounts as the destination, not only On This >Computer. > >It's true that some account types do not allow creating folders >directly at the top level, they allow creating only subfolders of >existing folders (like of the Inbox), but neither the On This Computer, >nor IMAP accounts, are part of that group. > Bye, > Milan > >___ >evolution-list mailing list >evolution-list@gnome.org >To change your list options or unsubscribe, visit ... >https://mail.gnome.org/mailman/listinfo/evolution-list ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] CalDAV is readonly
Hi Milan, I did some debugging too and I could get it working by fixing some bug in e_webdav_session_extract_privilege_simple in e-webdav-session.c. I believe the problem is the following: When the privlieges are retrieved from the server, the relevant XML snippet looks like this: As you can see, the privilege node contains the two child nodes, however when it's passed to e_webdav_session_extract_privilege_simple, the for loop stops after evaluating the first one due to the break statement and thus skips any further privileges. So basically it boiled down to e_webdav_session_extract_privilege_simple only returning a single privilege and not the whole set which I think was the bug. Maybe the for loop in e_webdav_session_current_user_privilege_set_cb was supposed to deal with this...? Anyway, my C is pretty rusty so I'd not consider my hacky workaround code any good but if you think it is of any use to clarify the problem, I can send you a diff. Cheers, Peter On Tue, 2020-01-14 at 11:28 +0100, Milan Crha via evolution-list wrote: > On Tue, 2020-01-14 at 07:43 +, Krauß, Peter (SCC) via evolution- > list wrote: > > I did indeed do several restarts (without success). > > Hi, > just to be clear, I didn't mean restart of the whole machine, but > restart of the calendar factory only, that is, of the > evolution-calendar-factory process. > > You even do not need to kill the process to be restarted, just close > evolution, open terminal and execute there: > >$ /usr/libexec/evolution-calendar-factory -w > > then wait for few seconds and only then start Evolution. Though I > think > you captured the log from the initial email in a very similar way and > it still did not work, thus this won't work as well. > > Maybe you can run DBus monitor and search what it passed around. You > might focus on "writable" and "Writable" (quotes for clarity only) > signals/properties. The command is: > >$ dbus-monitor > > then I see for example this after I open a calendar which had not > been > opened yet: > > > signal time=1578997003.522247 sender=:1.181 -> destination=(null > > destination) serial=878 > > path=/org/gnome/evolution/dataserver/Subprocess/6081/25; > > interface=org.freedesktop.DBus.Properties; member=PropertiesChanged > > string "org.gnome.evolution.dataserver.Calendar" > > array [ > > dict entry( > > string "Writable" > > variant boolean true > > ) > > ] > > array [ > > ] > > followed by a method invocation response: > > > method return time=1578997003.522745 sender=:1.181 -> > > destination=:1.226 serial=879 reply_serial=42 > > array [ > > string "alarm-email-address" > > string "''" > > string "cache-dir" > > . > > string "writable" > > string "true" > > ] > > this is how the backends notify the clients about their state, one of > them being writability. It's hard to recognize which calendar the > response belongs to, that why I'd try on one, which is not opened > yet. > Note the dbus-monitor output will be very chatty, quite many things > sends something over D-Bus all the time, thus expect interleaved > output. > Bye, > Milan > > ___ > evolution-list mailing list > evolution-list@gnome.org > To change your list options or unsubscribe, visit ... > https://mail.gnome.org/mailman/listinfo/evolution-list -- Peter Krauß Karlsruher Institut für Technologie (KIT) Steinbuch Centre for Computing (SCC) Forschungsgruppe Cloud Computing Hermann-von-Helmholtz-Platz 1 Gebäude 449/R105 76344 Eggenstein-Leopoldshafen Telefon: +49(0)721/608-26578 E-Mail: peter.kra...@kit.edu Web: http://www.kit.edu/ KIT - Universität des Landes Baden-Württemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
