Tuesday, 2021-09-21

poetasterrinigus: thanks.06:35
dcalisteHello chriadam, would you mind if we start earlier today ? I have an appoinment with colleagues at 7.30 UTC ?06:35
chriadamhi dcaliste, certainly06:35
dcalisteAbout 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
dcalisteAbout the QML plugins, I've addressed the remarks from pvuorela (hopefully).06:37
chriadambuteo-syncfw + nqpc right?06:38
chriadamI'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 far06:42
dcalisteGreat, thank you.06:42
dcalisteNow, I would like, if you agree, to discuss a bug I've found with calendar importation.06:43
chriadamthank you for your patience ;-)06:43
chriadamuh oh ;-)06:43
dcalisteThere are different way to solve it and I would like your advice.06:43
dcalisteI've received (from a Google calendar I think) a calendar event as ICS data and imported it.06:44
dcalisteThis 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
dcalisteThe importation went fine and the (lone) exception is displayed in the calendar properly.06:45
dcalisteBut, 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
dcalisteSo there are at least two possibilities:06:46
chriadamand I wonder what would happen if you tried to import the parent series ICS at this point, maybe a UID uniqueness problem06:46
dcalisteNo, I don't think so, because the exception has the recurrenceId set and the UNIQUE constrain is on UID+recId.06:47
chriadamah, ok06:47
dcalisteI think it would solve the problem to do this, indeed, but I would like to patch the root of it somehow.06:48
dcalisteSo 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
dcalisteThese 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
flypigForgive me for jumping in, but I thought we'd already done the former, in the exception creation code?06:54
dcalisteThat'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
dcalisteIndeed, third possibility is current case actually.06:55
dcalisteThe 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
dcalisteflypig: yes, CalDAV is creating already a fake parent when receiving a lone exception. But not the nemo-qml-plugin-calendar import code.06:56
flypigAh, I see. So the import had nothing to do with sync.06:58
flypigI misunderstood.06:58
dcalisteDoing 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
chriadamI'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
flypigWould it even make sense to reject the import?06:59
dcalisteThat'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
dcalisteflypig, 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
dcalisteFor 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
chriadamIMO that seems eminently sensible.  we should check to see whether google/eas sync does similar07:04
chriadamand then, as flypig mentioned, maybe we can add a simple check to import, to disallow importing a lone exception to a non-existent parent series07:05
dcalisteSo 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
dcalisteWell, besides the sync issue, I was happy to see my event in the calendar.07:06
chriadamhmm, well, that's true ...07:06
dcalisteIt served me well to have it in the calendar.07:06
chriadammaybe some "convert import to lone event, rather than exception event" ?07:06
chriadambut then that means if the parent series is imported in future .... bleh.07:07
dcalisteWhy not, but would break the case when I import the parent when I read the next emails…07:07
dcalisteIndeed !07:07
dcalisteThat's a tricky issue…07:07
dcalisteWith the sync allowing faulty events, it's not really an issue actually…07:08
dcalisteBesides the fact that it makes some useless roundtrips with the server at each syncs.07:08
chriadamI 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 sane07:09
dcalisteYes, that they are faulty tolerant on this.07:09
dcalisteThe 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
dcalisteThen the event would be flagged according to user choice and the sync plugin would behave accordingly.07:11
dcalisteThere could be some buttons added besides the warning label for faulty events in the event page for instance.07:12
chriadamyeah, that would be nice07:15
chriadamonce we get the sync log ui integrated07:15
chriadamI've created JB#55613 to track the issue at least07:15
chriadamthank you for raising that one07:15
chriadamI also saw a couple of other PRs you created recently, e.g. caldav PR#407:16
dcalisteWell, 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
dcalisteAt least, it helped me to test the error reporting !07:17
dcalisteWhich brings me to the two latest MRs for CalDAV :07:17
dcalisteand https://github.com/sailfishos/buteo-sync-plugin-caldav/pull/407:17
chriadamif 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
dcalisteThe first PR (#5) is about reporting error to the user when the etag is not updated properly.07:18
dcalisteIt'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
chriadamfor 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
dcalisteYes, 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
dcalisteI'm going to prepare a PR for this too.07:21
chriadamthank you very much07:22
chriadamaside from that, PR#5 LGTM.  would like pvuorela and flypig to take a look also if possible of course07:22
dcalisteI 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
dcalisteMaybe the second possibility is more intentional…07:23
dcalisteAbout PR#4, this one is more about functionalities.07:24
dcalisteI'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
chriadamfor 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 failure07:25
dcalisteThe 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
chriadamI 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 dunno07:26
dcalisteI 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
chriadamyup, true07:27
dcalisteMaybe 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
dcalisteHaving actions to treat the error should be on the UI side, based on flags with easy to understand labels.07:28
chriadamI agree07:28
chriadamI 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 ourselves07:29
chriadamwe can make that decision later ;-)07:29
chriadamso long as the error enum values are sufficient for generating the appropriate action labels07:29
chriadamand we don't need / want to use the extra error data for that07:29
chriadamI guess you have to go to your meeting now!  Thank you, as always, for your effort and help.  It is greatly appreciated.07:30
dcalisteIndeed, I agree. PR#4 is not covering accurate error enum. It's covering error logging.07:30
chriadamI will poke pvuorela about the buteo-syncfw PR, and also hopefully these two caldav PRs.07:30
chriadamthanks also for your writeup about Buteo for the newsletter!07:31
dcalisteAh 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
chriadamHave a good week!07:31
dcalisteNo 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
flypigThanks from me too; I really can't thank you enough for such a nice article.07:33
dcalisteBut thanks for adding them (at screenshots) they complement well the idea of a consistent and centralised sync framework.07:33
flypigI wasn't able to put in a screenshot of your logger I'm afraid. I just ran out of time.07:33
dcalisteNo 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
dcalisteEnjoy your week and see you later.07:35
flypigThank you, and you too!07:35
*** WoC is now known as Guest48309:22
x2sSadly bluetooth is still broken on my sfx after the update /cc mal11:58
malx2s: do you have any logs or other information that could help debugging it12:10
x2sthat's the strange part, I have none.12:12
x2sThere is nothing in the logs12:12
x2sit just looses the bt device12:30
x2sI had to restart the phone today, now hcitool dev shows hci0 as device12:31
x2sIt seems to happen with my car stereo. When my phone loses the connection to it then the device seems to disappear.12:32
x2sBut there is no segfault or anything in the journal12:32
x2sand I recently activatey persistant journals, so I can look days back now12:32
malnothing even in dmesg?12:48
maldmesg messages should appear in journal also12:48
x2sI 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 Guest54213:11
XenoPLHi, 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 chat16:54
XenoPLUnfortunatelly 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
XenoPLI'm asking becausr It the first xase it potentially can be fixed if the latter, not much can be done.16:58
attahXenoPL: Android apps aren't any more or less jailed than they used to be - and others can definitely access contacts17:19
XenoPLattah: 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
XenoPLI guesst i'm gonna try it in spare moment17:31
attahThat's the best guess... but i remember reading something about higher api level for contacts being fixed recently17:32
attahI don't use any of those "chat" apps, just comparing with my mobile payment app, it sees contacts just fine17:35
Mister_Magisterrinigus: ping21:36
Mister_Magisterhe asleep poor boi21:37

Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!