Hello, for some years now I use radicale with thunderbird as clients for contacts and calender. Works great exept the contact sync: changes through thunderbird get applied to the phone’s contacts, but on the phone it is impossible to add a contact to the cardav account. I’m forced to save new contacts in the phone’s memory, which of course don’t get synced to my thunderbird(s).
Was this not added in any 4.x release? Or soon ™ to come?
(not using DAV)
For me the calendar works with SyncEvolution, only Contacts does not as it changed the API after 3.4.
- buteo-syncfw compiled with bluez5 enabled
- openobex 1.5 (1.7 does not work)
- buteo-sync-plugins with bluez5. I do not know what current code supports, I did one branch, but it was removed when migrating from gitlab)
all compiled in the SDK
I’m curious what your device profile for SyncEvolution looks like.
You have a working buteo-syncfw / sync-plugins against bluez5 on 4.3? I mean, only for calendar?
@poetaster I have not tested this on 4.3 yet - lack of time, but on 4.1 it worked (except that BT had issues there). SynEvolution configuration is the same as it was always. The key here is that I ported the buteo-sync-plugin to bluez5, but my work vanished when sailfish left gitlab and I did not have the time to push to github yet.
This conversation is motivation to do it next - I’ll update you when done.
Thanks! I’ll stay tuned.
only Contacts does not as it changed the API after 3.4.
If you have a moment to point me in which file it is broken in syncml plugin, I can give a look if you are interested in.
1 Like
Damien, thank you for showing up here and being open and willing to help as before.
I just checked briefly the status and prepared to rebase on current master, but it will take some time to accommodate the last changes. So perhaps 1-2 days (I hope I have the time in the evening).
The problem with Contacts is that it was not working already before as something around the storage use changed. I have to look into the chats to see what the Sailors said back then.
./storageplugins/hcontacts/ContactsBackend.cpp iReadMgr and iWriterMgr
I remember that someone mentioned that something changed in the way how Sailfish is now handling these storage backends and I need an appropriate filter or so, but I did not have the time to sit down and work it in a proper way.
If I change some contact on the phone, I can sync to the PC, but the other way around is not working. This is where I left it before the summer and was busy with finding/starting new project for living until now.
If you can have a look what changed in the way backend storage is handled it would be great.
3 Likes
Thank you for the pointers. I’ll try to give a look. Contact storage is something I wanted to learn about for a while. So why not by looking at this. Since, it’s not my domain of knowledge it may take a bit of time. But I’ll try to help if I can.
1 Like
Can I add that I stopped using syncevolution a long time ago, and use the caldav/cardav account sync for a long time now? So I was addressing my issue in that context, not with syncevolution in between. To conclude, syncing contacts works for me one way, from pc (radicale) to phone, but not in the other direction. I remember a time when this worked in 2 directions … .
I have to reconstruct the details from memory of what happened beginning of this year as all conversations we had on gitlab are gone.
Now I remember that pvuorela merged my patch for bluez5 to buteo-syncfw and disabled bluez5 in commits 96d60a0b3302920cf66ee047ca2c50a82ed9d59a, bb85bcf32ba5240e5089888c2778551a0e1cce58.
I was not able to build or use this and was told that in production is still 0.9.18. I started working on patching this version so that I could test, but I guess I never made it and gave up.
I think I was desperate and gave up because of lack of time.
I will try to see if what I have prepared for buteo-syncfw 0.9.18 works on 4.3 and will post back
Updates: I found out that in 4.3 the latest buteo-syncfw builds and installs.
The problem is now commit:
627f9f5 (tag: 0.8.32, origin/master, master) Merge pull request #1 from sailfishos/jb53712-logging in buteo-sync-plugins.
I can not rebase and I can not build. I will look forward to push it to github and see if one of you can rebase and/or fix something.
master:
* 627f9f5 (tag: 0.8.32, origin/master, master) Merge pull request #1 from sailfishos/jb53712-logging |\ | * 2b8597d [buteo-sync-plugins-social] Use own logging categories instead of Buteo LOG_* macros. JB#53712 |/ * 18359cc (tag: 0.8.31) Merge branch 'buteo_enum_type' into 'master' |\ | * 83760eb Adjust syncmlserver errors as hopefully more appropriate | * 0b1561e [buteo-sync-plugins] Adjust buteo error signal typing. Contributes to JB#31584 | * a087bab Add some common types to .gitignore |/
my test branch
* c5770fa (HEAD -> feat/bluez5calsync) Changes necessary to prevent server crashing if client sync is triggered automatically * 8e56c49 Update to use bluez5 with kf5bluezqt * 745a36c [buteo-sync-plugins] Enable calendar synchronization over Bluetooth. Contributes to MER#1222 * 18359cc (tag: 0.8.31) Merge branch 'buteo_enum_type' into 'master' |\ | * 83760eb Adjust syncmlserver errors as hopefully more appropriate | * 0b1561e [buteo-sync-plugins] Adjust buteo error signal typing. Contributes to JB#31584 | * a087bab Add some common types to .gitignore |/
Strange, have you pushed your development branch somewhere already ? I don’t see any fork in Github yet.
@dcaliste
No, not in github. It was in gitlab and is all gone now. I was very busy during the summer and autumn and missed to secure the information. On top my motivation was very low as the changes introduced lately were complex and I had to sit down and concentrate for more than 1-2 hours, that I would have in the evening.
I have to read now how it works in github - probably later today/tomorrow and I can push there.
I have one spare Xperia X for testing but I see that Bluetooth is broken there (the issue I reported with hciattach). I was hoping I can use it for testing, before installing on the X 10 II. Now I have to find a way to solve this bug before being able to test 
repo: git@github.com:deloptes/buteo-sync-plugins.git
branch: feat/bluez5
- includes Calendar sync patch from Chris Adams and my changes for bluez5
- Contacts does not work properly as mentioned. I will push one other branch with what I tested and had some kind of working but bizzare result - and this is where I stopped
- I used this until 3.3.0.16 where I froze work on that as explained before
- you need to compile buteo-syncfw with HAVE_BLUEZ5 enabled
- I use to add debugging to msyncd
- in rpm/buteo-sync-plugins-qt5.spec change Name to buteo-syncml-plugins-qt5 (otherwise it breaks things - or at least it was the case before - never had time to investigate)
- you need openobex-1.5 (I will push after I evaluate what I changed - I think it was dependency on bluez4 that I removed there)
- I also compile and install buteo-syncml, but I do not think it is necessary - I have never checked if there are some dependencies - just to be sure
Thank you in advance.
@dcaliste I added feat/bluez5-pre-3.4 branch with the code before I started porting to the version after 3.4
I also fixed a FTBFS in feat/bluez5. It now builds and I was able to sync contacts and calendar+todos with SyncEvolution.
I must test this in the next days.
If you are willing to review and help improving the code. It would be great. Then we could officially request merging.
Let’s move technical details now to the github site.
My solution for this is a nextcloud account on a Raspberry WITHOUT internet connection. I have a small “Intranet” running in my house with clients, that I do not want to have on the internet. So I have just an access-point to it an sync contacts this way.
Best regards,
Lukas
@lukas_jolla2015
Appreciate your input, but it is off topic as we are discussing here the option to sync without WLAN
Sorry for that, I understood “offline” in the meaning not using the internet and not in the way not using wlan as interface.
Best regards,
Lukas
@lukas_jolla2015
N.P - in my opinion the best way is to use the BT as it is local and does not require cables or additional settings … even not a developer mode