| poetaster | rinigus: thanks. | 06:35 |
|---|---|---|
| dcaliste | Hello chriadam, would you mind if we start earlier today ? I have an appoinment with colleagues at 7.30 UTC ? | 06:35 |
| chriadam | hi dcaliste, certainly | 06:35 |
| dcaliste | About logging Buteo syncs, there are the two pending PRs, one about QML bindings and one adding a new model in calendar qml plugin. | 06:37 |
| dcaliste | About the QML plugins, I've addressed the remarks from pvuorela (hopefully). | 06:37 |
| chriadam | buteo-syncfw + nqpc right? | 06:38 |
| dcaliste | Exactly. | 06:39 |
| dcaliste | https://github.com/sailfishos/buteo-syncfw/pull/1 | 06:39 |
| dcaliste | https://github.com/sailfishos/nemo-qml-plugin-calendar/pull/2 | 06:39 |
| chriadam | I'll poke pvuorela again, seems like we're pretty close to getting the first one in, at least, and the second one seems non-controversial so far | 06:42 |
| dcaliste | Great, thank you. | 06:42 |
| dcaliste | Now, I would like, if you agree, to discuss a bug I've found with calendar importation. | 06:43 |
| chriadam | thank you for your patience ;-) | 06:43 |
| chriadam | sure | 06:43 |
| chriadam | uh oh ;-) | 06:43 |
| dcaliste | There are different way to solve it and I would like your advice. | 06:43 |
| dcaliste | I've received (from a Google calendar I think) a calendar event as ICS data and imported it. | 06:44 |
| dcaliste | This event was in fact an orphan exception (I guess I received the parent one in another email, but I didn't import it somehow). | 06:44 |
| dcaliste | The importation went fine and the (lone) exception is displayed in the calendar properly. | 06:45 |
| dcaliste | But, then we have an orphan exception in the database and the CalDAV sync plugin is reporting error on it because it cannot find a parent to create the ICS data to upload it. | 06:45 |
| chriadam | indeed | 06:46 |
| dcaliste | So there are at least two possibilities: | 06:46 |
| chriadam | and I wonder what would happen if you tried to import the parent series ICS at this point, maybe a UID uniqueness problem | 06:46 |
| dcaliste | No, I don't think so, because the exception has the recurrenceId set and the UNIQUE constrain is on UID+recId. | 06:47 |
| chriadam | ah, ok | 06:47 |
| dcaliste | I think it would solve the problem to do this, indeed, but I would like to patch the root of it somehow. | 06:48 |
| dcaliste | So the two possibilities I foresee: | 06:48 |
| dcaliste | - we patch the importation routine to apply the same trick than CalDAV is doing by creating a parent based on the exception. | 06:48 |
| dcaliste | - we patch the sync code to send the lone exception. | 06:48 |
| dcaliste | These two possibilities have severe drawbacks in my opinion: | 06:49 |
| dcaliste | - first is a huge code modification because we need to import first the ICS data in a memory calendar, then for each incidence, load the corresponding one from the DB to check if we have a parent and create a fake one in case we have no. Basically a dupplicate of all the updateIncidences() code from caldav plugin to be put in nemo-qml-plugin-calendar… Ugly. | 06:51 |
| dcaliste | - by doing so we may also break a future importation of the parent event when the user (me) finally discovered that I received it by email earlier. | 06:52 |
| dcaliste | - the second possibility patching CalDAV sync plugin, is broken for most of the servers. I tried with my OpenExchange server to send it an orphan exception, it failed. | 06:53 |
| flypig | Forgive me for jumping in, but I thought we'd already done the former, in the exception creation code? | 06:54 |
| dcaliste | That's where I am, stuck at two dead ends. Luckily, now sync is not stopping on an error, and everything goes well, except for this lone exception. | 06:54 |
| chriadam | - third possibility: detect the orphan exception case and just refuse to upsync such orphans. but allow downsyncing them or otherwise importing them. shrug. | 06:54 |
| dcaliste | Indeed, third possibility is current case actually. | 06:55 |
| dcaliste | The incidence is flagged as faulty and the user knows about it. But flagging it faulty makes the sync to be labelled as failed (not a big deal) and make the sync plugin to retry to upload it on next sync (and so on). | 06:56 |
| dcaliste | flypig: yes, CalDAV is creating already a fake parent when receiving a lone exception. But not the nemo-qml-plugin-calendar import code. | 06:56 |
| flypig | Ah, I see. So the import had nothing to do with sync. | 06:58 |
| flypig | I misunderstood. | 06:58 |
| dcaliste | Doing the same in the importation code could create more issues than solving this one I think. Indeed, a later importation of the parent (I'm not reading email in the right order for this for instance) will fail. | 06:58 |
| chriadam | I'm inclined to go with option 3, even though it requires some changes to every sync plugin: detect if event is orphan, if so, just skip it. mark it as failed to upsync. | 06:59 |
| flypig | Would it even make sense to reject the import? | 06:59 |
| chriadam | interesting | 07:00 |
| dcaliste | That's the current situation already. The only drawback of it is (at least for CalDAV), the event is retired and reflagged at each sync in that case. | 07:00 |
| dcaliste | flypig, I may agree. We have two areas to patch: | 07:00 |
| chriadam | (but is it the current case? e.g. if you import the exception even to an exchange calendar, did you say that the exchange sync will fail?) | 07:01 |
| dcaliste | - the sync plugins, because we may have orphan in the db for whatever reason. | 07:01 |
| dcaliste | - the importation routine, should it be allowed or not. | 07:01 |
| dcaliste | For exchange code, I don't know chriadam, but for caldav that's the step by step (at each sync): | 07:02 |
| dcaliste | - the orphan has no etag and it's UID is not server so an upload is required, | 07:02 |
| dcaliste | - the upload fails because the sync plugin code refuse to generate an orphan ICS data, | 07:03 |
| dcaliste | - the event is flagged for the user to notice it, | 07:03 |
| dcaliste | - the sync is marked as failed (but continue for the other items). | 07:03 |
| chriadam | IMO that seems eminently sensible. we should check to see whether google/eas sync does similar | 07:04 |
| chriadam | and then, as flypig mentioned, maybe we can add a simple check to import, to disallow importing a lone exception to a non-existent parent series | 07:05 |
| dcaliste | So we may keep it as it is and let the user decide : does he want to delete the faulty event on device ? Or keep it retired and reflagged at each sync and ignore it ? | 07:05 |
| chriadam | yeah. | 07:05 |
| dcaliste | Well, besides the sync issue, I was happy to see my event in the calendar. | 07:06 |
| chriadam | hmm, well, that's true ... | 07:06 |
| dcaliste | It served me well to have it in the calendar. | 07:06 |
| chriadam | maybe some "convert import to lone event, rather than exception event" ? | 07:06 |
| chriadam | but then that means if the parent series is imported in future .... bleh. | 07:07 |
| dcaliste | Why not, but would break the case when I import the parent when I read the next emails… | 07:07 |
| dcaliste | Indeed ! | 07:07 |
| dcaliste | That's a tricky issue… | 07:07 |
| dcaliste | With the sync allowing faulty events, it's not really an issue actually… | 07:08 |
| dcaliste | Besides the fact that it makes some useless roundtrips with the server at each syncs. | 07:08 |
| chriadam | I will create an internal bug for this now, so that it doesn't slip off radar. At very least, we need to ensure google + eas sync is sane | 07:09 |
| dcaliste | Yes, that they are faulty tolerant on this. | 07:09 |
| dcaliste | The best solution (and it's something I started to think about last week-end) would be for the user to have a UI to make action on faulty events. Something like: | 07:10 |
| dcaliste | - notice that an event don't sync (we flag them already and report them in the UI), | 07:10 |
| dcaliste | - present actions in that case like "ignore this event for future sync", "delete the event", "retry at next sync". | 07:11 |
| dcaliste | Then the event would be flagged according to user choice and the sync plugin would behave accordingly. | 07:11 |
| dcaliste | There could be some buttons added besides the warning label for faulty events in the event page for instance. | 07:12 |
| chriadam | yeah, that would be nice | 07:15 |
| chriadam | once we get the sync log ui integrated | 07:15 |
| chriadam | I've created JB#55613 to track the issue at least | 07:15 |
| chriadam | thank you for raising that one | 07:15 |
| chriadam | I also saw a couple of other PRs you created recently, e.g. caldav PR#4 | 07:16 |
| dcaliste | Well, I was happy with the sync plugin, didn't have any issue for a long time, thinking that it began to be reasonably bug free, up to last week ;) | 07:16 |
| dcaliste | At least, it helped me to test the error reporting ! | 07:17 |
| dcaliste | Which brings me to the two latest MRs for CalDAV : | 07:17 |
| dcaliste | https://github.com/sailfishos/buteo-sync-plugin-caldav/pull/5 | 07:17 |
| dcaliste | and https://github.com/sailfishos/buteo-sync-plugin-caldav/pull/4 | 07:17 |
| chriadam | if anything, it's an import bug. the caldav plugin is robust. we just need to make sure google+eas are also, I think. | 07:17 |
| dcaliste | The first PR (#5) is about reporting error to the user when the etag is not updated properly. | 07:18 |
| dcaliste | It's not supposed to change any behaviour, but report that the sync was at least partial (even if all data were sometimes transfered). | 07:19 |
| chriadam | for that one, I agree that we should differentiate between "sync failed" and "sync succeeded with item errors". the "sync failed" one suggests e.g. losing connectivity halfway through or something, whereas the "succeeded with item errors" is more like "the sync cycle succeeded, and some items may need user intervention" | 07:20 |
| dcaliste | Yes, it 's an idea that appeared when reading your comment. The more I think about it, the more I'm convinced that it's a good idea to add this to Buteo. | 07:21 |
| dcaliste | I'm going to prepare a PR for this too. | 07:21 |
| chriadam | thank you very much | 07:22 |
| chriadam | aside from that, PR#5 LGTM. would like pvuorela and flypig to take a look also if possible of course | 07:22 |
| dcaliste | I need to see if I add it as a new value in the Major enum (success_with_item_failures), or keep the major as success and add a minor like item_error. | 07:22 |
| dcaliste | Maybe the second possibility is more intentional… | 07:23 |
| dcaliste | About PR#4, this one is more about functionalities. | 07:24 |
| dcaliste | I've refactored a bit the request code to store the server message. | 07:24 |
| chriadam | (sure minor code of item_specific_errors or something makes sense) | 07:24 |
| chriadam | for PR#4 I agree definitely that the more information we can provide the user, the better chance they will be able to take action to resolve the failure | 07:25 |
| dcaliste | The idea is to store it in case of error in the Buteo log. So the advanced user can have clue or report to the forum issues without having to rerun the case with debug on by hand with msyncd. | 07:25 |
| chriadam | I do worry that whenever dealing with "action" messages, they should be translated, I think. so either the action strings need to be based on the error codes (rather than the extra error data) or ... I dunno | 07:26 |
| dcaliste | I agree. But I think logging and action are two different things. We need to treat them separately. The logging is mainly for advanced usage, to report issues on forum from live error without having to fallback to running msyncd by hand. | 07:27 |
| chriadam | yup, true | 07:27 |
| dcaliste | Maybe this information will never be presented to the UI actually, but we can ask the user to copy-paste it from log files. | 07:28 |
| dcaliste | Having actions to treat the error should be on the UI side, based on flags with easy to understand labels. | 07:28 |
| chriadam | I agree | 07:28 |
| chriadam | I don't necessarily see any harm in showing the extra information in the sync log UI somewhere (some drilldown for advanced users) but ... let's not get too far ahead of ourselves | 07:29 |
| chriadam | we can make that decision later ;-) | 07:29 |
| chriadam | so long as the error enum values are sufficient for generating the appropriate action labels | 07:29 |
| chriadam | and we don't need / want to use the extra error data for that | 07:29 |
| chriadam | I guess you have to go to your meeting now! Thank you, as always, for your effort and help. It is greatly appreciated. | 07:30 |
| dcaliste | Indeed, I agree. PR#4 is not covering accurate error enum. It's covering error logging. | 07:30 |
| chriadam | I will poke pvuorela about the buteo-syncfw PR, and also hopefully these two caldav PRs. | 07:30 |
| chriadam | thanks also for your writeup about Buteo for the newsletter! | 07:31 |
| dcaliste | Ah yes, time's up. Thank you for your help and discussion. It's clearer for me now the directions to take for the various PR we dealt with. | 07:31 |
| chriadam | Great | 07:31 |
| chriadam | Have a good week! | 07:31 |
| dcaliste | No problem for the Buteo article. There are parts that I didn't covered well, because I don't know them much, like file syncing, or Twitter case (like I can see in the screenshots). | 07:32 |
| flypig | Thanks from me too; I really can't thank you enough for such a nice article. | 07:33 |
| dcaliste | But thanks for adding them (at screenshots) they complement well the idea of a consistent and centralised sync framework. | 07:33 |
| flypig | I wasn't able to put in a screenshot of your logger I'm afraid. I just ran out of time. | 07:33 |
| dcaliste | No problem, it's too advanced anyway for 99% of the audience at the moment. I needed to compile 4 different packages to make it work yesterday on a fresh 4.3.0 base… And sometimes branches that were not yet master ones. | 07:34 |
| dcaliste | Enjoy your week and see you later. | 07:35 |
| flypig | Thank you, and you too! | 07:35 |
| *** WoC is now known as Guest483 | 09:22 | |
| x2s | Sadly bluetooth is still broken on my sfx after the update /cc mal | 11:58 |
| mal | x2s: do you have any logs or other information that could help debugging it | 12:10 |
| x2s | that's the strange part, I have none. | 12:12 |
| x2s | There is nothing in the logs | 12:12 |
| x2s | it just looses the bt device | 12:30 |
| x2s | I had to restart the phone today, now hcitool dev shows hci0 as device | 12:31 |
| x2s | It seems to happen with my car stereo. When my phone loses the connection to it then the device seems to disappear. | 12:32 |
| x2s | But there is no segfault or anything in the journal | 12:32 |
| x2s | and I recently activatey persistant journals, so I can look days back now | 12:32 |
| x2s | *activated | 12:33 |
| mal | nothing even in dmesg? | 12:48 |
| mal | dmesg messages should appear in journal also | 12:48 |
| x2s | I will look again, when the phone is charged. My wifi has some trouble and the new card for my ap hasn't arrived yet. (Never use an intel card as ap...) | 12:50 |
| *** fifr[m] is now known as Guest542 | 13:11 | |
| XenoPL | Hi, I've got a question kinda related to SFOS to anyone using WhatsApp. Is anyone using up-to-date WhatsAp on SFOS <4.0 (ie no app jail)? Does it see contacts stored on the phone? | 16:51 |
| XenoPL | Here around 4.0 release WhatsApp shows only past chats and connections, but it says "No WhatsApp contacts" when I try to start a new chat | 16:54 |
| XenoPL | Unfortunatelly at the same time they introduced their unfamous new privacy policy, which not accepted resulted in WhatsApp being useless (no contacts to be seen). So i'm wondering is it fireail broke WA or it is something on WA/Facebook side. | 16:57 |
| XenoPL | I'm asking becausr It the first xase it potentially can be fixed if the latter, not much can be done. | 16:58 |
| attah | XenoPL: Android apps aren't any more or less jailed than they used to be - and others can definitely access contacts | 17:19 |
| XenoPL | attah: thanks, so it in theory if I could roll back WA to older release it should access contacts just fine (assuming such old releases are not blocked on WA servers) | 17:31 |
| XenoPL | I guesst i'm gonna try it in spare moment | 17:31 |
| attah | That's the best guess... but i remember reading something about higher api level for contacts being fixed recently | 17:32 |
| attah | I don't use any of those "chat" apps, just comparing with my mobile payment app, it sees contacts just fine | 17:35 |
| Mister_Magister | rinigus: ping | 21:36 |
| Mister_Magister | he asleep poor boi | 21:37 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!