evolution-data-server issueshttps://gitlab.gnome.org/GNOME/evolution-data-server/-/issues2023-12-20T20:58:27Zhttps://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/507sqlite3_enable_shared_cache is deprecated2023-12-20T20:58:27ZDamian Marcin Szymańskisqlite3_enable_shared_cache is deprecatedHi.
Evolution-data-server by default trying to use `sqlite3_enable_shared_cache` but it is deprecated in current version of sqlite https://www.sqlite.org/sharedcache.html
Sqlite has option to remove the obsolete shared cache mode with ...Hi.
Evolution-data-server by default trying to use `sqlite3_enable_shared_cache` but it is deprecated in current version of sqlite https://www.sqlite.org/sharedcache.html
Sqlite has option to remove the obsolete shared cache mode with results in a less size and better performance https://www.sqlite.org/compile.html#omit_shared_cache
Some distributions already compile sqlite without this option, which causes an evolution-data-server build error like this:
```
ld.lld: error: undefined symbol: sqlite3_enable_shared_cache
DEBUG util.py:446: >>> referenced by camel-db.c:450 (/builddir/build/BUILD/evolution-data-server-3.50.2/src/camel/camel-db.c:450)
DEBUG util.py:446: >>> lto.tmp:(init_sqlite_vfs)
```
Similar bug report was reported to other gnome project like tracker https://gitlab.gnome.org/GNOME/tracker/-/issues/411https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/506alarm-notify: Birthday floating date shifted by one day2023-12-20T20:58:27ZBrian J. Murrellalarm-notify: Birthday floating date shifted by one dayevolution-notify (3.50.1-1.fc39) mis-represents birthdays as being one day before they actually are. For example:
![image](/uploads/eeec7fda8b878a54cb174f7ba8982941/image.png)
Yet the actual contact info shows one day later:
![image]...evolution-notify (3.50.1-1.fc39) mis-represents birthdays as being one day before they actually are. For example:
![image](/uploads/eeec7fda8b878a54cb174f7ba8982941/image.png)
Yet the actual contact info shows one day later:
![image](/uploads/973739600229018f8f0f32dae8d88acc/image.png)https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/505alarm-notify: Some reminders could be lost2023-12-20T20:58:27ZVictor Engmarkalarm-notify: Some reminders could be lostI'm using GNOME Evolution 3.48.1 as my main calendar app, with the calendar itself hosted with Google. Lately a lot of alerts have been showing up at completely the wrong time. Right now (2023-10-21 00:00:00 Pacific/Auckland) I got an al...I'm using GNOME Evolution 3.48.1 as my main calendar app, with the calendar itself hosted with Google. Lately a lot of alerts have been showing up at completely the wrong time. Right now (2023-10-21 00:00:00 Pacific/Auckland) I got an alert for an event starting at 2023-10-20 16:00:00 Pacific/Auckland (six hours ago) configured with a reminder to "Pop up an alert 1 hour before the start". That is, the alert was supposed to show up *seven hours ago*. (Thankfully, Google Calendar on my Android phone does the right thing and showed an alert at the right time.)
`/etc/localtime` is symlinked to `../etc/zoneinfo/Pacific/Auckland`.https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/504Evolution-data-server should notify of new emails even when Evolution's main ...2023-11-03T12:32:52ZJulien OlivierEvolution-data-server should notify of new emails even when Evolution's main window is closed.When you close Evolution's main window, you don't get notifications when new emails arrive. I think e-d-s should be able to notify users of new emails.When you close Evolution's main window, you don't get notifications when new emails arrive. I think e-d-s should be able to notify users of new emails.https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/503[Feature Request] Exchange ActiveSync support2023-10-31T12:41:32ZJordan Maris[Feature Request] Exchange ActiveSync supportSupport for Exchange ActiveSync would enable the use of Gnome in more business environments that still rely on Microsoft's EAS.Support for Exchange ActiveSync would enable the use of Gnome in more business environments that still rely on Microsoft's EAS.https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/502DBUS_SERVICES_PREFIX should be configurable in config files2023-11-22T08:34:59ZOwen TaylorDBUS_SERVICES_PREFIX should be configurable in config filesWe're switching the way Flatpaks are built in Fedora so that a *single* build of evolution-data-server will be used in all Flatpaks. The current way DBUS_SERVICES_PREFIX is compiled into the EDS binaries makes this difficult to handle.
...We're switching the way Flatpaks are built in Fedora so that a *single* build of evolution-data-server will be used in all Flatpaks. The current way DBUS_SERVICES_PREFIX is compiled into the EDS binaries makes this difficult to handle.
See: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7MPO4UCZUDU3BHMFNFPCSFAEKSMQYLD4/
What would be better if the D-Bus service files were generated as something like:
```
BusName=org.example.MyApp.org.gnome.evolution.dataserver.AddressBook10
ExecStart=/usr/libexec/evolution-addressbook-factory --dbus-services-prefix=org.example.MyApp
```
Then at Flatpak container creation time, a script could rename and substitute the config files as appropriate for the app being built.
See
https://src.fedoraproject.org/rpms/tracker-miners/c/664a298a51e0ce435323aa3065c4325d47cb0685?branch=rawhide
https://src.fedoraproject.org/flatpaks/gnome-music/c/7eb118437a4d1bcb72458fa8520eb20926d451a5?branch=stable
For an example of how something similar is being done for tracker-minershttps://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/500Disable building tests in CMake2023-09-13T11:02:27ZDark DragonDisable building tests in CMakeIs there a way to disable building tests in CMake?
I already set `ENABLE_INSTALLED_TESTS=OFF` but it still builds tests when running `make` without arguments.Is there a way to disable building tests in CMake?
I already set `ENABLE_INSTALLED_TESTS=OFF` but it still builds tests when running `make` without arguments.https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/499addressbook-export: Do not translate `--format` arg description2023-09-14T07:00:54ZДилян Палаузовgit-dpa@aegee.orgaddressbook-export: Do not translate `--format` arg descriptionRunning `strace addressbook-export --help` prints
```
write(1, "Usage:\n addressbook-export [OPT"..., 359Usage:
addressbook-export [OPTION…]
Help Options:
-h, --help Show help options
Application Options:
...Running `strace addressbook-export --help` prints
```
write(1, "Usage:\n addressbook-export [OPT"..., 359Usage:
addressbook-export [OPTION…]
Help Options:
-h, --help Show help options
Application Options:
--output=OUTPUTFILE Specify the output file instead of standard output
-l, --list-addressbook-folders List local address book folders
--format=csv] Show cards as vcard or csv file
) = 359
```
Instead of `--format=csv]` it shall print `--format=[vcard|csv]` or similarhttps://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/498vCard: Incorrectly parses non-UTF-8 vCard data2024-03-20T07:22:20ZIvan KorytovvCard: Incorrectly parses non-UTF-8 vCard data**Steps to reproduce:**
1. Get a vCard from Outlook with cyrillic charset (Windows-1251)
2. Try to import vCard in Evolution
3. Get garbled output
![evolution-vcard-1](/uploads/0f71223d7650b201af470c385057948f/evolution-vcard-1.jpg)
**...**Steps to reproduce:**
1. Get a vCard from Outlook with cyrillic charset (Windows-1251)
2. Try to import vCard in Evolution
3. Get garbled output
![evolution-vcard-1](/uploads/0f71223d7650b201af470c385057948f/evolution-vcard-1.jpg)
**Expected result:**
Correct display of fields in contact card.
Test vCard contains CHARSET in fields, and correctly opens in text editor
![evolution-vcard-2](/uploads/6ef018c408df303711acb4dabf675567/evolution-vcard-2.jpg)
**Versions:**
- OS: ALT Linux Workstation K x86_64 (updated to latest unstable packages)
- Evolution: 3.48.4
**Attachment:**
[test-vcard.vcf](/uploads/16824273d7a35b54b5ba5efa637f3025/test-vcard.vcf)https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/497IMAP: Cache does not refresh after UIDVALIDITY changes2024-02-19T12:23:13ZLeander BeernaertIMAP: Cache does not refresh after UIDVALIDITY changesHello!
I'm using Evolution 3.48.4 (3.48.4-1.module_f38+17164+63eeee4a from flathub) and I'm experiencing an issue where the mail cache does not update after an UIVALIDITY change in a Mailbox. This was initially reported through a user r...Hello!
I'm using Evolution 3.48.4 (3.48.4-1.module_f38+17164+63eeee4a from flathub) and I'm experiencing an issue where the mail cache does not update after an UIVALIDITY change in a Mailbox. This was initially reported through a user regarding some invalid state they were experiencing and I managed verify the behavior locally on my setup.
I'm using Evolution with the latest version of Proton Bridge (3.4.1-beta). Regardless of what value we change the UIDVALIDITY to (lesser or higher than the previous value) has no effect.
I was hoping if you could confirm if this is a known issue? I have also tested against Thunderbird, which correctly refreshes the full state.
Edit: I have the evolution client frozen in this invalid state. If there is anything you wish me to try, please let me know.https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/496Build fails when using libphonenumber 8.13.192023-08-25T14:33:53ZKrassy Boykinovkboykinov@teamcentrixx.comBuild fails when using libphonenumber 8.13.19Hello,
after trying to upgrade `libphonenumber` to `8.13.19` (in context of an Alpine Linux [MR](https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/50386)), the `evolution-data-server` does not go beyond the CMake check stage...Hello,
after trying to upgrade `libphonenumber` to `8.13.19` (in context of an Alpine Linux [MR](https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/50386)), the `evolution-data-server` does not go beyond the CMake check stage:
<details><summary>Build log</summary>
```
CMake Deprecation Warning at CMakeLists.txt:3 (cmake_minimum_required):
Compatibility with CMake < 3.5 will be removed from a future version of
CMake.
Update the VERSION argument <min> value or use a ...<max> suffix to tell
CMake that the project does not need compatibility with older versions.
CMake Deprecation Warning at CMakeLists.txt:4 (cmake_policy):
Compatibility with CMake < 3.5 will be removed from a future version of
CMake.
Update the VERSION argument <min> value or use a ...<max> suffix to tell
CMake that the project does not need compatibility with older versions.
-- The C compiler identification is GNU 13.1.1
-- The CXX compiler identification is GNU 13.1.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PkgConfig: /usr/bin/pkg-config (found version "2.0.2")
-- Checking for module 'gobject-introspection-1.0>=1.59.1'
-- Found gobject-introspection-1.0, version 1.76.1
-- Found Gettext: /usr/bin/msgmerge (found version "0.22")
-- Checking for modules 'krb5;krb5-gssapi'
-- Found krb5, version 1.21.2
-- Found krb5-gssapi, version 1.21.2
-- Using MIT Kerberos 5 (found by pkg-config)
-- Performing Test openldap_2_x
-- Performing Test openldap_2_x - Success
-- Looking for res_query in resolv
-- Looking for res_query in resolv - found
-- Looking for __res_query in resolv
-- Looking for __res_query in resolv - not found
-- Looking for bind in socket
-- Looking for bind in socket - not found
-- Looking for ber_get_tag in lber
-- Looking for ber_get_tag in lber - found
-- Looking for ldap_open in ldapMR
-- Looking for ldap_open in ldap - found
-- Performing Test phone_number_with_boost_thread-mt
-- Performing Test phone_number_with_boost_thread-mt - Failed
-- Performing Test phone_number_with_boost_thread
-- Performing Test phone_number_with_boost_thread - Failed
CMake Error at cmake/modules/FindPhonenumber.cmake:72 (message):
libphonenumber cannot be used. Use -DWITH_PHONENUMBER=PATH to specify the
library prefix, or -DWITH_PHONENUMBER=OFF to disable it.
Call Stack (most recent call first):
CMakeLists.txt:292 (include)
```
</details>
It was compiled using the following command:
```
CFLAGS="$CFLAGS -I/usr/include/gnu-libiconv" \
cmake -B build -G Ninja \
-DCMAKE_INSTALL_PREFIX=/usr \
-DSYSCONF_INSTALL_DIR=/etc \
-DCMAKE_BUILD_TYPE=None \
-DENABLE_GOA=ON \
-DENABLE_INTROSPECTION=ON \
-DENABLE_VALA_BINDINGS=ON \
-DWITH_PHONENUMBER=ON \
-DWITH_LIBDB=OFF \
-DENABLE_SCHEMAS_COMPILE:BOOL=OFF \
-DENABLE_OAUTH2_WEBKITGTK4=ON
cmake --build build
```
Thank you for your helphttps://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/495ESource emits property change signals in the source_registry_object_manager_t...2023-08-23T15:11:55ZGeorges Basile Stavracas NetoESource emits property change signals in the source_registry_object_manager_thread() threadThis was a tough nut to crack.
I was investigating a crash in Calendar, and wrote some thread validation helpers as part of that. These validation functions exposed something unexpected (which may or may not be the source of the crashes...This was a tough nut to crack.
I was investigating a crash in Calendar, and wrote some thread validation helpers as part of that. These validation functions exposed something unexpected (which may or may not be the source of the crashes - I don't know yet).
ESourceRegistry spawns a thread to communicate with the D-Bus server, and tries really hard to emit signals and property changes in the GMainContext in which it was created. This is its documented behaviour, even: https://gitlab.gnome.org/GNOME/evolution-data-server/-/blob/master/src/libedataserver/e-source-registry.c#L39-41
However, I think it was bitten by the D-Bus generated code. The recent patches in Calendar gave the following callstack:
```
Thread 7 "gnome-calendar" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffeb7fe6c0 (LWP 28)]
0x00007ffff6a90e14 in __pthread_kill_implementation () from /usr/lib/x86_64-linux-gnu/libc.so.6
> bt
#0 0x00007ffff6a90e14 in __pthread_kill_implementation () at /usr/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff6a3edce in raise () at /usr/lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff6a2683f in abort () at /usr/lib/x86_64-linux-gnu/libc.so.6
#3 0x00007ffff70dff4b in g_assertion_message_expr[cold] () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x00007ffff714a0f7 in g_assertion_message_expr () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00005555555cb452 in remove_all_events (self=0x55555734d190) at ../src/core/gcal-calendar-monitor.c:1019
#6 0x00005555555cbe81 in on_calendar_visible_changed_cb (calendar=0x5555557a59f0, pspec=0x555555695930, self=0x55555734d190) at ../src/core/gcal-calendar-monitor.c:1200
#7 0x00007ffff707043a in g_closure_invoke () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#8 0x00007ffff708496c in signal_emit_unlocked_R.isra.0 () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#9 0x00007ffff70863f1 in signal_emit_valist_unlocked () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#10 0x00007ffff708c3c1 in g_signal_emit_valist () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#11 0x00007ffff708c483 in g_signal_emit () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#12 0x00007ffff7074a94 in g_object_dispatch_properties_changed () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#13 0x00007ffff7077c07 in g_object_notify_by_pspec () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#14 0x0000555555586992 in on_source_visible_changed_cb (source=0x5555557d9440, pspec=0x5555557706c0, self=0x5555557a59f0) at ../src/core/gcal-calendar.c:146
#15 0x00007ffff707043a in g_closure_invoke () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#16 0x00007ffff708496c in signal_emit_unlocked_R.isra.0 () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#17 0x00007ffff70863f1 in signal_emit_valist_unlocked () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#18 0x00007ffff708c3c1 in g_signal_emit_valist () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#19 0x00007ffff708c483 in g_signal_emit () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#20 0x00007ffff7074a94 in g_object_dispatch_properties_changed () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#21 0x00007ffff7075448 in g_object_notify_queue_thaw () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#22 0x00007ffff7077d5e in g_object_thaw_notify () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#23 0x00007ffff6e299fc in source_load_from_key_file (object=0x5555557d9440, key_file=key_file@entry=0x7fffd40ffc90, group_name=0x5555556ffeb0 "Calendar") at /run/build/evolution-data-server/src/libedataserver/e-source.c:702
#24 0x00007ffff6e2a4a8 in source_parse_dbus_data (source=source@entry=0x7fffd40ffc30, error=error@entry=0x7fffeb7fcde0) at /run/build/evolution-data-server/src/libedataserver/e-source.c:789
#25 0x00007ffff6e2a680 in source_notify_dbus_data_cb (dbus_source=<optimized out>, pspec=<optimized out>, source=0x7fffd40ffc30) at /run/build/evolution-data-server/src/libedataserver/e-source.c:806
#26 0x00007ffff707043a in g_closure_invoke () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#27 0x00007ffff708496c in signal_emit_unlocked_R.isra.0 () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#28 0x00007ffff70863f1 in signal_emit_valist_unlocked () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#29 0x00007ffff708c3c1 in g_signal_emit_valist () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#30 0x00007ffff708c483 in g_signal_emit () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#31 0x00007ffff7074a94 in g_object_dispatch_properties_changed () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#32 0x00007ffff7077b0f in g_object_notify () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#33 0x00007ffff59e5c6c in e_dbus_source_proxy_g_properties_changed (_proxy=0x7fffd400bef0, changed_properties=<optimized out>, invalidated_properties=0x7fffe0045650) at /run/build/evolution-data-server/src/private/e-dbus-source.c:1709
#34 0x00007ffff707043a in g_closure_invoke () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#35 0x00007ffff7084ff8 in signal_emit_unlocked_R.isra.0 () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#36 0x00007ffff70863f1 in signal_emit_valist_unlocked () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#37 0x00007ffff708c698 in g_signal_emit_by_name () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#38 0x00007ffff734dc51 in signal_cb () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#39 0x00007ffff7329240 in emit_signal_instance_in_idle_cb () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#40 0x00007ffff711ac97 in g_main_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#41 0x00007ffff711cda7 in g_main_context_iterate_unlocked.isra () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#42 0x00007ffff711d757 in g_main_loop_run () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#43 0x00007ffff6e45716 in source_registry_object_manager_thread (data=0x5555557b8570) at /run/build/evolution-data-server/src/libedataserver/e-source-registry.c:1167
#44 0x00007ffff714bcb9 in g_thread_proxy () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#45 0x00007ffff6a8ee39 in start_thread () at /usr/lib/x86_64-linux-gnu/libc.so.6
#46 0x00007ffff6b16cc4 in clone () at /usr/lib/x86_64-linux-gnu/libc.so.6
```
Notice that:
* The thread is **Thread 7**
* It seems to come from D-Bus generated code (`e_dbus_source_proxy_g_properties_changed`)
* It completely bypasses `registry->priv->main_context`
* The signal in question comes from `ESourceSelectable`, and that's `notify::selected`https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/494Update default calendar colors2023-10-19T10:18:54ZTobias BernardUpdate default calendar colorsBy default, GNOME Calendar comes with two calendars, both of which come with colors that aren't part of our color palette. "Personal" in particular uses a very washed out blue, which doesn't fit in at all with the rest of our UI.
I was ...By default, GNOME Calendar comes with two calendars, both of which come with colors that aren't part of our color palette. "Personal" in particular uses a very washed out blue, which doesn't fit in at all with the rest of our UI.
I was told these colors are coming from e-d-s, so I'm filing the issue here. If that's not the case, feel free to move it elsewhere :)https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/493Use collection source also when it has no auth method set2023-08-30T14:32:31ZДилян Палаузовgit-dpa@aegee.orgUse collection source also when it has no auth method setWith Evolution 3.36.5 I add a WebDAV-only Collection account for user aaa@aegee.org with password abc .
I setup a second WebDAV-only collection account for user aaa@milter.aegee.org with password abc and I enter manually as server ma...With Evolution 3.36.5 I add a WebDAV-only Collection account for user aaa@aegee.org with password abc .
I setup a second WebDAV-only collection account for user aaa@milter.aegee.org with password abc and I enter manually as server mail.aegee.org .
The CalDAV server delivers different content for authenticated and not authenticated users.
For aaa@milter.aegee.org: When I go in the Accounts editor, select a collection and click on Browse, Evolution asks for password, when the collection requires password to be accessed. If the collection can be accessed without password, then Evolution opens the WebDAV editor normally and does not ask for password. For the account aaa@milter.aegee.org the 'personal' addressbook and the 'personal' calendar require password, so the WebDAV editor asks (several times) for password upon 'Browse', if I click every time 'Cancel'.
For the aaa@aegee.org account, the WebDAV editor always asks for password.
• When the user clicks 'Cancel' after Evolution asks for http-password, Evolution shall not ask again.
• After the user has permanently (repeatedly) cancelled the password prompt, The Evolution account editor is not focused, but should.
• Since the account is configured in Evolution with password, Evolution shall memorize this fact and not ask for password for the password-protected resources ('personal' AB and calendar), but use the remembered password.https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/492The Schedule tab in CompEditor looks suboptimal in Dark mode2023-08-10T07:48:17ZДилян Палаузовgit-dpa@aegee.orgThe Schedule tab in CompEditor looks suboptimal in Dark modeTimes at the top are rendered in black text on dark gray background.Times at the top are rendered in black text on dark gray background.https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/491gi-docgen installing CMakeFiles2023-08-09T08:50:08ZJeremy Bichagi-docgen installing CMakeFiles- evolution-data-server 3.49.2
- Debian Unstable
- gi-docgen 2023.1
- CMake 3.27.1
When I build evolution-data-server with `-DENABLE_GI_DOCGEN=ON`, there are some installed files that I would not expect to be installed:
```
drwxr-xr-x ...- evolution-data-server 3.49.2
- Debian Unstable
- gi-docgen 2023.1
- CMake 3.27.1
When I build evolution-data-server with `-DENABLE_GI_DOCGEN=ON`, there are some installed files that I would not expect to be installed:
```
drwxr-xr-x root/root 0 2023-08-04 10:27 ./usr/share/doc/camel/CMakeFiles/
-rw-r--r-- root/root 725 2023-08-04 10:27 ./usr/share/doc/camel/CMakeFiles/CMakeDirectoryInformation.cmake
drwxr-xr-x root/root 0 2023-08-04 10:27 ./usr/share/doc/camel/CMakeFiles/gtkdoc-camel.dir/
-rw-r--r-- root/root 461 2023-08-04 10:27 ./usr/share/doc/camel/CMakeFiles/gtkdoc-camel.dir/DependInfo.cmake
-rw-r--r-- root/root 4175 2023-08-04 10:27 ./usr/share/doc/camel/CMakeFiles/gtkdoc-camel.dir/build.make.gz
-rw-r--r-- root/root 226 2023-08-04 10:27 ./usr/share/doc/camel/CMakeFiles/gtkdoc-camel.dir/cmake_clean.cmake
-rw-r--r-- root/root 122 2023-08-04 10:27 ./usr/share/doc/camel/CMakeFiles/gtkdoc-camel.dir/compiler_depend.make
-rw-r--r-- root/root 116 2023-08-04 10:27 ./usr/share/doc/camel/CMakeFiles/gtkdoc-camel.dir/compiler_depend.ts
-rw-r--r-- root/root 21 2023-08-04 10:27 ./usr/share/doc/camel/CMakeFiles/gtkdoc-camel.dir/progress.make
drwxr-xr-x root/root 0 2023-08-04 10:27 ./usr/share/doc/camel/CMakeFiles/gtkdoc-rebuild-camel-sgml.dir/
-rw-r--r-- root/root 461 2023-08-04 10:27 ./usr/share/doc/camel/CMakeFiles/gtkdoc-rebuild-camel-sgml.dir/DependInfo.cmake
-rw-r--r-- root/root 2039 2023-08-04 10:27 ./usr/share/doc/camel/CMakeFiles/gtkdoc-rebuild-camel-sgml.dir/build.make.gz
-rw-r--r-- root/root 232 2023-08-04 10:27 ./usr/share/doc/camel/CMakeFiles/gtkdoc-rebuild-camel-sgml.dir/cmake_clean.cmake
-rw-r--r-- root/root 135 2023-08-04 10:27 ./usr/share/doc/camel/CMakeFiles/gtkdoc-rebuild-camel-sgml.dir/compiler_depend.make
-rw-r--r-- root/root 129 2023-08-04 10:27 ./usr/share/doc/camel/CMakeFiles/gtkdoc-rebuild-camel-sgml.dir/compiler_depend.ts
-rw-r--r-- root/root 1 2023-08-04 10:27 ./usr/share/doc/camel/CMakeFiles/gtkdoc-rebuild-camel-sgml.dir/progress.make
-rw-r--r-- root/root 2 2023-08-04 10:27 ./usr/share/doc/camel/CMakeFiles/progress.marks
-rw-r--r-- root/root 404 2023-08-04 10:27 ./usr/share/doc/camel/CTestTestfile.cmake
-rw-r--r-- root/root 1856 2023-08-04 10:27 ./usr/share/doc/camel/Makefile.gz
```https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/490EBookMetaBackend: Changes from refresh() not propagated to the opened views2023-08-07T09:47:14ZChris TalbotEBookMetaBackend: Changes from refresh() not propagated to the opened viewsHello!
I use `EBookClientView`'s `Object added` https://source.puri.sm/Librem5/chatty/-/blob/master/src/chatty-contact-provider.c#L350 to watch for additions to an address book. This does fine for local CardDav changes (e.g., I add one ...Hello!
I use `EBookClientView`'s `Object added` https://source.puri.sm/Librem5/chatty/-/blob/master/src/chatty-contact-provider.c#L350 to watch for additions to an address book. This does fine for local CardDav changes (e.g., I add one through GNOME Contacts). However, I added a contact on a different computer to the same CardDav address book. When e-d-s synced and added that contact, I noticed it did not emit a, `Object added` signal.
I think this signal should be emitted if there was a changed server side and e-d-s notices the change.https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/488Camel: Filtering Search folder leaves changed messages in the result2023-08-30T14:32:29ZMassimo-BCamel: Filtering Search folder leaves changed messages in the resultEvolution-3.42.4
Hello,
I have a Search folder as configured below. If I do a search in that Search folder using the quick Search: bar, using "Body contains", it leaves some mails in the result that are not matching the filter. For ins...Evolution-3.42.4
Hello,
I have a Search folder as configured below. If I do a search in that Search folder using the quick Search: bar, using "Body contains", it leaves some mails in the result that are not matching the filter. For instance if the correct result is 3 messages, I still see 5 messages with 2 that I had opened before.
In order to repair the result I need to switch to another Search folder and back to the filtered one. That cleans out the bad residuals and shows the correct filter result.
The used Search Folder is a nested Search Folder, using another Search folder.
Search Folders
**10 weeks**
```
any of the following conditions
Include threads: None
Date received is after 10 weeks ago
Date sent is after 10 weeks ago
[x] Automatically update...
Specific folders:
Search Folders: "All" [ ] include subfolders
```
**All**
```
any of the following conditions
Include threads: None
Match All
[x] Automatically update...
Specific folders:
MyImap: INBOX [ ] include subfolders
MyImap: Sent [ ] include subfolders
```https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/487IMAPx: Messages unexpectedly deleted from Inbox2023-08-30T14:32:28ZRob FoehlIMAPx: Messages unexpectedly deleted from InboxI found several old messages from my IMAP inbox sitting in my Trash folder, and was able to capture Evolution deleting messages from INBOX unexpectedly, annotated here for clarity:
```
[imapx:A] I/O: 'A05564 UID MOVE 17251 Trash'
^ De...I found several old messages from my IMAP inbox sitting in my Trash folder, and was able to capture Evolution deleting messages from INBOX unexpectedly, annotated here for clarity:
```
[imapx:A] I/O: 'A05564 UID MOVE 17251 Trash'
^ Delete recent message from folder A
[imapx:A] I/O: 'A05658 UID MOVE 17252:17253 Trash'
^ Delete recent messages from folder A
[imapx:A] I/O: 'A05670 UID MOVE 17254 Trash'
^ Delete recent message from folder A
[imapx:A] I/O: 'A05697 UID MOVE 9358 Trash'
^ Delete recent message from folder B
[imapx:A] I/O: 'A05715 UID MOVE 29605:29606 Trash'
^ Delete recent messages from folder C
[imapx:A] I/O: 'A05816 UID MOVE 616793 Trash'
^ Delete recent message from INBOX
[imapx:A] I/O: 'A05835 UID MOVE 29607 Trash'
^ Delete recent message from folder C
[imapx:A] I/O: 'A06578 UID MOVE 17255 Trash'
^ Delete recent message from folder A
[imapx:A] I/O: 'A06603 UID MOVE 29608:29609 Trash'
^ Delete recent messages from folder C
[imapx:A] I/O: 'A06974 UID MOVE 9359 Trash'
^ Delete recent message from folder B
[imapx:A] I/O: 'A07180 UID MOVE 558945 Trash'
^ Uncommanded delete of old message from INBOX
[imapx:A] I/O: 'A07191 UID MOVE 15552,15572,15575,15578,15588:15589,15598,15619:15620 Trash'
^ Delete recent messages from folder D
[imapx:A] I/O: 'A07212 UID MOVE 366689 INBOX'
^ Manually move what had been 558945 back to INBOX
[imapx:A] I/O: 'A08458 UID MOVE 616795 Trash'
^ Delete another recent message from INBOX
[imapx:B] I/O: 'B08501 UID MOVE 559030 Trash'
^ Uncommanded delete of another old message from INBOX
[imapx:A] I/O: 'A10213 UID MOVE 29610 Trash'
^ Delete recent message from folder C
[imapx:B] I/O: 'B10231 UID MOVE 29611 Trash'
^ Delete recent message from folder C
```
The UIDs in the 55xxxx range are (very) old messages in INBOX, and are higher than all other folders, which invalidated my original theory that smaller UIDs from other folders were being applied to INBOX. Maybe an index into an array of UIDs used by operations on the wrong folder?
I have no easy reproducer, nor do I know exactly what's triggering this -- my best guess is that this is happening during fairly rapid deletions among multiple folders, but so far it's only occurred maybe a dozen times over several weeks. The two instances shown above were maybe 20-30 minutes apart, with that log covering all of the moves/deletions over an hour or two.
This is with Evolution 3.48.4 on Fedora 38, with the default 3 connections and 3 second delay; unclear when it started or on what release, as I've mostly used Evolution with an EWS account and the IMAP account is a recent addition.https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/486ECollator: Always include Latin/English letters2023-08-30T14:32:29ZДилян Палаузовgit-dpa@aegee.orgECollator: Always include Latin/English lettersIn the new Address book cards I see on the very right a list of letters, that allow me to jump to the contacts starting with that letter. I have in my address book contact names in Cyrillic and Latin.
The problem report is that the lis...In the new Address book cards I see on the very right a list of letters, that allow me to jump to the contacts starting with that letter. I have in my address book contact names in Cyrillic and Latin.
The problem report is that the list of letters contains only the Cyrillic letters and for all the other it has horizontal ellipsis (possibly at the same time above and below the Cyrillic letters).
![hor](/uploads/b842978556c62a2cbad68f69b34bdf96/hor.png)