| chriadam | hi dcaliste, how are you today? | 06:59 |
|---|---|---|
| dcaliste | Hello Chris, I'm ok. I hope you're well too. | 07:03 |
| chriadam | yep, not too bad, thanks | 07:04 |
| chriadam | unfortunately I didn't get a chance to follow up on your PRs from last week, yet | 07:04 |
| dcaliste | No problem, don't worry. | 07:05 |
| chriadam | have been busy this last week with another project, unfortunately. This week I have more availability, fortunately. | 07:05 |
| dcaliste | I created some new ones. We can review them. | 07:05 |
| chriadam | great | 07:05 |
| dcaliste | https://github.com/sailfishos/buteo-syncfw/pull/5 about a minor error code in Buteo to say that sync was successful but some items may have failed. | 07:06 |
| dcaliste | I added simply a new value in the enum. But if you see the comment, I'm actually wondering about the "SUCCESSFUL" one. | 07:07 |
| chriadam | does that syncAgentConsts.h have any documentation about that SYNC_FINISHED case? | 07:09 |
| dcaliste | I tried to find this file without any success. I even checkout the repo to the moment the line was added, but I didn't find it there neither. | 07:10 |
| chriadam | heh. | 07:10 |
| chriadam | I think SYNC_FINISHED does indeed suggest that the sync completed, and that since it's different to NO_ERROR that it suggests that some (per item) errors occurred | 07:11 |
| chriadam | but I haven't thought about it much yet, nor do I remember what that code has been used for in the past. I might grep the syncml plugin to see if it is used currently... | 07:11 |
| chriadam | ah! that syncAgentConsts.h exists in the buteo-syncml plugin btw | 07:12 |
| dcaliste | Indeed, that's my opinion also. But would "major: SUCCESS, minor: FINISHED" would suggest that there are some non fatal issues with some items ? | 07:12 |
| dcaliste | Ah, ok. Great, looking at it. | 07:13 |
| chriadam | it looks like from the SyncML plugin, SYNC_FINISHED is a "pure success" state, so I would tend to lean toward adding a new error code for this case | 07:14 |
| chriadam | but maybe I'm wrong | 07:14 |
| dcaliste | Would you in that case agree with the name of the new value ? | 07:15 |
| chriadam | naming is hard | 07:16 |
| chriadam | I have no concerns with that name, honestly | 07:16 |
| chriadam | it's explicit. | 07:17 |
| chriadam | and descriptive. | 07:17 |
| dcaliste | I see in SyncAgentConsts.h. It's to map values. But it's a bit strange since the two enums seem not to be used in the same context. | 07:17 |
| chriadam | yeah. buteo things. | 07:17 |
| dcaliste | Anyway, I'll update slightly the PR to mentioned in the comment where to find the SyncAgentConsts.h file. | 07:18 |
| chriadam | thanks | 07:18 |
| chriadam | were there any other new PRs? from last week's PRs, I don't think either pvuorela or flypig have had a chance to look at the caldav#4 or caldav#5 PRs yet, but they LGTM. | 07:20 |
| dcaliste | When looking into issues on importing ics data, I found this one : https://github.com/sailfishos/mkcal/pull/7 | 07:21 |
| dcaliste | It's not an issue at the moment, since the code-path to get it is not taken. But it may be in the future. | 07:22 |
| dcaliste | I'm commenting there on two ways to solve it. | 07:22 |
| dcaliste | The problem is the following scheme: | 07:22 |
| dcaliste | - delete entry with UID = foo, | 07:22 |
| dcaliste | - add a new incidence with UID = foo. | 07:22 |
| dcaliste | In that case, it's failing because deletion is done after addition. | 07:23 |
| chriadam | added a couple of comments | 07:31 |
| chriadam | I'm a bit worried that the second solution you mention could break the "second" ordering in transactions (i.e. add+delete) | 07:32 |
| dcaliste | Indeed, good point. It invalidation the reordering. | 07:33 |
| dcaliste | So the porposed way to convert DEL+ADD into UPDATE is a better way. | 07:33 |
| chriadam | I think so, yes | 07:33 |
| chriadam | but not 100% sure if the (add+delete) case even makes sense (within a single transaction) | 07:34 |
| chriadam | so I might be wrong | 07:34 |
| dcaliste | Sure, but in case, we could keep it possible. | 07:36 |
| chriadam | yep | 07:37 |
| dcaliste | And a last new PR : https://github.com/sailfishos/contactsd/pull/1 | 07:37 |
| dcaliste | Mostly targetting flypig, but mentioning i today in case you're interested. | 07:38 |
| dcaliste | It seems from forum report that Google still has some issues with disabled calendars being reenable after sync. | 07:38 |
| dcaliste | I cannot reproduce at the moment (didn't try hard neither). | 07:38 |
| dcaliste | But the only possibility I can imagine of, is the contactsd plugin that flip the visibility of notebooks, depending on enabled status of the account. | 07:39 |
| dcaliste | If I'm not mistaken, the callback can be called even when the enable status is not changed because of internal implementation of libaccount. | 07:40 |
| dcaliste | If that's true, we cannot trust in the callback that the enabled status actually changed. | 07:40 |
| dcaliste | We try to mitigate this earlier by trying hard not to save account if there is no change, but if there are changes actually, we cannot avoid it. | 07:41 |
| dcaliste | So I'm proposing to try to patch this by saving notebook visibility status and reset it properly in the enabled status callback. | 07:41 |
| dcaliste | It's not perfect, but it should solve the problem in most cases, as far as I can see. | 07:42 |
| chriadam | so the issue is that a (Google) notebook can have its visibility flipped to false (or vice versa) due to an account save? | 07:43 |
| dcaliste | Yes, particularly to visible, while the user hide it, during a sync. | 07:44 |
| dcaliste | I think we can have the same issue with caldav when we change something to the account. I'm going to try to demonstrate it during this week. | 07:44 |
| dcaliste | Maybe it will help to reproduce the forum reports. | 07:45 |
| flypig | Sorry for not already having looked at your PR dcaliste. I didn't notice it until chriadam just prodded me now. | 07:46 |
| dcaliste | Don't worry flypig. No problem. | 07:46 |
| dcaliste | I created it lately last week anyway. It's not in a hurry. | 07:47 |
| flypig | I recall the problem, but haven't yet digested your fix. | 07:47 |
| flypig | Or why it's different for Google accounts specifically. | 07:48 |
| dcaliste | That's what I cannot understand. The only syncAndBlock I can see in the Google plugin is when there is a need to upsdate credentials. | 07:48 |
| dcaliste | Which cannot happen at each sync… | 07:49 |
| dcaliste | That's why I have trouble to reproduce the forum reports. | 07:49 |
| dcaliste | Before accepting the PR, it's definitely important to demonstrate which situation could lead to the issue the PR tries to address. | 07:50 |
| chriadam | this might be completely unrelated, but the contactsd plugin thing might be triggered directly by jolla-calendar | 07:50 |
| chriadam | (although I might be crossing wires here) | 07:50 |
| flypig | It'd certainly be good to understand what's going on. I'll take a look and also try to reproduce it this week. | 07:51 |
| dcaliste | What makes me think the culprit is around there is when you grep for setIsVisible in the code : there is no match in the google sync plugin. | 07:51 |
| dcaliste | The only place where you have it is nemo-qml-plugin-calendar, but it's not supposed to be used during a sync. | 07:51 |
| dcaliste | And the other place I know about is the contactsd plugin… | 07:52 |
| flypig | So you think the only possibility is a syncAndBlock call. | 07:52 |
| dcaliste | If it's the contactsd plugin, then it's because of a enabled status changed signal from the AccountManager. | 07:52 |
| dcaliste | And a possible way to trigger it (if I'm not wrong, not 100% sure), is a syncAndBlock(). | 07:53 |
| flypig | Okay, that makes sense. | 07:53 |
| dcaliste | (a sync() also, but it seems that it's not used, but more difficult to grep for) | 07:53 |
| flypig | There's probably some messy stuff going on in the Settings, but I didn't check the forum post; could that be causing problems? | 07:55 |
| flypig | "reappear again randomly or after sync". Randomly suggests it's on a timed sync. | 07:56 |
| dcaliste | The reproducing procedure is not clear from the posters ;) But at least two people seem to see the problem. I'm not sure it implies the setting application though. | 07:56 |
| flypig | Right. | 07:56 |
| chriadam | I have another meeting in a couple of minutes, so we might need to wrap this one up, unfortunately | 07:57 |
| dcaliste | Yes, I'm more incline to think about something triggered during the buteo sync. But the only syncAndBlock calls are for credentials need update, which is not coherent with posters situation… | 07:57 |
| chriadam | quick summary: I will merge those two caldav PRs this week, unless pvuorela or flypig have some comments on those | 07:57 |
| dcaliste | No problem chriadam, sure. Just a word to say that I finally updated the DST jolla-calendar MR. | 07:58 |
| chriadam | I have poked Pekka again about the buteo-syncfw one, let's see if that one progresses | 07:58 |
| chriadam | ah! should I poke MartinS about that one again? | 07:58 |
| chriadam | I mentioned it to him and Joona internally. thanks for that! | 07:59 |
| dcaliste | Yes, I still have no clue on how to make the reminder work, but at least for the UI design in the month view, it's updated. | 07:59 |
| chriadam | great, thanks very much | 07:59 |
| chriadam | I have to run - have a great week! | 07:59 |
| * chriadam -> away, gnight :-) | 07:59 | |
| dcaliste | thank you chriadam, see you. | 07:59 |
| flypig | I have the same meeting, so will also dash, but thank you again for your great work on the buteo article dcaliste. It seemed to go down well :) | 08:00 |
| dcaliste | Yeh, it was interesting to write it. | 08:00 |
| dcaliste | Have a nice meeting flypig. | 08:01 |
| flypig | Thanks, and have a nice day yourself! | 08:01 |
| Chat-ron | hi ! I'm trying to sync my contacts from my SFOS phone to my radicale server, but it doesn't seem to work : my SFOS phone can connect to my carddav srv, but doesn't seem to send any contact | 08:44 |
| Chat-ron | is it possible to sync local contacts to a carddav server ? | 08:44 |
| dcaliste | Chat-ron, I'm not sure, but I think that you can not sync "local" contacts to a server. You need to export your local contacts into one vcard file and then upload this file to your radical server. After that, you can create a CardDAV account on the phone and sync with your radical server. | 10:04 |
| Chat-ron | I see, thanks dcaliste | 11:05 |
| Chat-ron | but in this case, should I also remove the local contacts in order to have no duplicates or will it be handle by SFOS ? | 11:06 |
| dcaliste | I guess you will have duplicates… | 11:07 |
| Chat-ron | hum, and does the nextcloud account handle the contact sync ? | 11:10 |
| dcaliste | Yes, Nextcloud has a possibility to sync contacts. But it will be the same issue than with your Radical server : the contact are local and not associated to an online service. | 11:35 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!