| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
They're far too noisy, and make it difficult to spot new C compiler
warnings, which are the only ones I care about. We can enable them
again when we're serious about cleaning them up. In the meantime,
they're just getting in the way.
(cherry picked from commit e8ecbd7356caf9e3a4668a71224c60cce2bf94bf)
|
|
|
|
|
|
| |
Rationale explained in the source code.
(cherry picked from commit fab2ee606fad729edafc9a22379a26c01b1f0eb5)
|
|
|
|
|
|
|
|
|
| |
For uid->len = 318320, timing the loop yields:
g_list_append(): 60+ seconds
g_list_prepend(): 0.3 seconds
(cherry picked from commit ffd4d6931fd5af8624610825dd026139a6926a38)
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
(cherry picked from commit 1bfd6765d4684ab91842aabb87604badf80b52c0)
|
| |
|
| |
|
| |
|
|
|
|
| |
Not certain this is everything, just what I could find.
|
|
|
|
|
|
|
| |
It is unnecessary to test validity of the 'object' parameter,
especially when this callback does nothing with it. The reason
is that the secret_password_store() calls the callback with NULL
'object', which leads to a deadlock on the source registry side.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
For some reason we were calling camel_stream_write_string() without
passing a GError, and on failure setting a very generic error message
and losing potentially useful information about the actual error.
(cherry picked from commit 3ea35694702692ad17895e5751146127606e591d)
|
|
|
|
| |
(cherry picked from commit 52f87cba60b4d65a3d91718c25afc66d34db7db5)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 99f0208d4005f2650729c9b63a629c17e1cd964b.
This reverts my revert, since I mistakenly thought it was breaking the
ESourceCollection API. The solution is not ideal, but is fine as a
stop-gap measure for Evolution-Data-Server 3.6.x.
In 3.7.x I've added an e_source_registry_check_enabled() function and
swapped out most of the e_source_get_enabled() calls throughout Evo and
EDS, which obviates the need to keep enabled states for child sources
sychronized with parent sources at all times.
|
|
|
|
|
|
| |
There was no error handling at all on the write-to-stream operations.
(cherry picked from commit b46171b645a7e120fc25d627d84f07bea964d17c)
|
|
|
|
|
|
|
|
| |
The function is failable and takes a GError, yet returns void. This
is how GErrors pile up. Return a boolean and add the necessary error
checks where the function is called.
(cherry picked from commit 687ac881cf58df2e01dc509c007321f758b0c9d2)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
imapx_stop_idle() returned a boolean but TRUE had an ambiguous
interpretation. It either meant the DONE command was sent or an I/O
error occurred. Define a new enum type (CamelIMAPXIdleStopResult) to
resolve the ambiguity.
Also imapx_command_idle_stop() returned a boolean but FALSE had an
ambiguous interpretation. It either meant an I/O error occurred, or
there was no available CamelIMAPXStream from which to issue the DONE
command. Resolve the ambiguity by forcing callers to explicitly pass
in a CamelIMAPXStream (and a GCancellable, while we're at it).
(cherry picked from commit 21a5722a814e91e7224978e26ce86c751f6fe017)
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This reverts commit 20d7ae7dd4ba86a65a74a05146d6c143a725c3c4.
Need to find a better solution than corrupting what are supposed to be
separate state flags.
|
| |
|
|
|
|
|
|
|
|
| |
These functions were never meant to be exported. The "static" keyword
seems to have been omitted by accident. Can't find any evidence of them
being called from outside camel-imapx-server.c, so just make them static.
(cherry picked from commit 8a77efaa3f94ec1a6aa4743c72e1a0b34163e8b8)
|
|
|
|
|
|
| |
One argument per line.
(cherry picked from commit bc4f85db1f4efabe6c991fdccec00209a5b8c863)
|
|
|
|
|
|
|
| |
Normally I throw away all disabled-with-no-explanation-why code chunks,
but in this case they all seem related, so clarify that in the code.
(cherry picked from commit 0fa4740592cf6aa06a552e4b8af724083e35f404)
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Close our prompt before storing the password in the keyring.
If the keyring is locked, it will need to prompt the user for
a keyring password, but it can't do that if our password prompt
is still open since both prompts are system-modal. Not sure what
would happen next; probably the store operation would either fail
or deadlock.
(cherry picked from commit d4e32002bfae7e48a83da10dfe53d17efafb74c6)
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|