Tuesday, 2020-07-07

*** zbenjamin is now known as Guest8591101:24
*** zbenjamin_ is now known as zbenjamin01:24
*** frinring_ is now known as frinring02:35
*** svartoyg_afk is now known as svartoyg05:58
jrayhawknemo-devicelock claims to support a "number of tries", but, as near as I can tell, this is a fanciful lie and it just uses the LUKS header instead. How can I convince it to use policy-protected storage?06:16
jrayhawkhttps://together.jolla.com/question/220695/sailfish-3-numeric-pin-as-luks-passphrases-make-device-encryption-useless/ wait, this is seriously an unresolved problem after six months?06:36
AJAX555horray for 5 number long pin, gets cracked in 2 microseconds06:43
dcalisteHello chriadam !07:07
chriadamhi dcaliste07:07
chriadamI hope your week went well!07:08
dcalisteYes, thanks. What about yours ?07:09
chriadammy week was ok, thanks07:09
chriadamalthough, due to branching etc approaching, I didn't manage to spend any time reviewing your PRs unfortunately.  although I saw that Pekka reviewed your qmf change, which is good07:10
dcalisteI would like to ask you about contactsd, see https://together.jolla.com/question/229248/carddav-sync-draining-battery-by-continiously-resyncing-due-to-an-error07:10
chriadamlet me check07:11
dcalisteNo problem for the pending MRs, they will be checked and included after the branching no problem.07:12
dcalisteAbout the problem at hand in the TJC question, the reporter see continuous sync attempts, something like every 10s of contacts.07:13
dcalisteI was blaming Buteo first but looking closely at the logs he provided, I convinced the problem come from repeated DBus calls to startSync().07:13
dcalisteNot Buteo that requeue failing sync by itself.07:14
dcalisteMy first thought for external calls every seconds went to a daemon, it cannot be UI. So I suspected contactsd.07:14
chriadamcould very well be07:15
dcalisteI don't know much its code, but grepping for "startSync" in a DBus call triggered the plugin that is supposed to upsync local changes in automatically sync mode.07:15
chriadammy memory is very hazy, but there are a couple of possibilities at least:07:16
dcalisteThere is a timer there to coaless multiple changes to the contact db, and this timer is indeed 10s…07:16
chriadamhuh, well, that sounds like a smoking gun07:16
dcalisteThe possible scenario is then :07:17
chriadamI thought it had a backoff though?07:17
dcalisteCarddav is called at normal time, and is making a change to the db, but fails at one point and does not complete the sync. The modification is catched by contactsd and 10s later it asked for a sync. Then carddav apply the same failing modification and abort. 10s later contactsd see the modification and ask for a sync…07:18
dcalisteSo the backoff is not triggered, its a loop between carddav and contactsd.07:19
dcalisteMy question is more related to carddav in fact ;)07:19
dcalisteDo you think it's possible to actually do a modification then fail, and at next sync redo the same modification ?07:19
dcalisteIn caldav, like some etags that would not be updated ?07:19
chriadamanything's possible, due to bugs07:20
dcalisteYeh, but would design allow this kind of scenario, I mean a modification that is always redone at each sync ?07:20
dcalisteWhen sync fails of course.07:20
dcalisteFrom the logs, the syncs are failing.07:20
chriadamcontact sync is so hideously complex because of a terrible design decision we made back before jolla 1 launched, so that contacts aren't properly separated into addressbooks, but are aggregated for the appropriate sync target according to heuristics, basically.07:21
dcalisteThe reporter sent the carddav sync log yesterday, but I didn't have time to investigate it yet.07:21
dcalisteOk, there is a design point in contactsd that I would like to ask about also :07:22
chriadamooi what triggers the contactsd side again?  does it listen to a QContactManager for change signals, or what?07:22
dcalisteYes that's the case : QContactManager, as far as I remember.07:22
chriadambecause my naive assumption is that carddav plugin would do all changes in transaction, and if anything fails, entire transaction should be rolled back07:22
dcalisteLet me check again…07:22
chriadamin which case there should be no signals sent from QContactManager --> but perhaps I'm mistaken07:22
dcalisteYes indeed, it's QContactManager.07:24
dcalisteThat's why I was asking, because the fact that carddav could trigger a modification signal at each trial seems a bit suspicious even if all other pieces seems to match.07:25
dcalisteOtherwise, do you have any idea which daemon (or UI) that could call "startSync" on DBus every 10 s ?07:25
dcalisteThat part I pretty sure that the sync process in Buteo comes from a DBus call.07:26
chriadamI definitely expect it's contactsd07:26
chriadambut I think it might not directly be related to the carddav failure per se07:26
chriadambut rather, the non-privileged to privileged database sync07:27
dcalisteBecause in the logs, it all starts with "Start sync requested for profile:" with schedule = false, which from my investigation in buteo, can only come from a DBus call.07:27
chriadamcontactsd is responsible to syncing non-privileged database changes to the privileged database (and vice versa for some specific subset of the data in the privileged database)07:27
dcalisteYes, it's in the same exporter plugin from what I see.07:28
dcalisteLet me show you what I know from contactsd :07:28
dcaliste- startSync DBus call is done from Syncrigger object in src/synctrigger.cpp.07:28
dcaliste- this synctrigger exports itself on DBus, see ./src/contactsd.cpp:      mSyncTrigger(new SyncTrigger(&mDBusConnection))07:29
dcaliste- only exporter plugin is calling "SyncTrigger" from DBus.07:30
dcalistesee ./plugins/exporter/cdexportercontroller.cpp:                QStringLiteral("/SyncTrigger"07:30
chriadamyes, the syncTrigger exists as a horrible hack to implement "sync automatically / sync on change" support.  it is e.g. invoked by jolla-contacts whenever the app is opened, or if a contact is modified, IIRC.07:30
chriadambut the fact that the contactsd exporter plugin ALSO calls it is ... very suspicious (the exporter plugin exists SOLELY to export data to non-privileged db etc)07:31
dcalisteWell, I think that this automatically sync on change is called by the exporter plugin in contactsd, isnt't it ?07:31
chriadamso I highly suspect that the non-privileged to privileged db sync is causing the issue here.  i.e. a change is made in non-privileged, which gets synced to privileged by exporter, then that change itself triggers the exporter again07:31
dcalisteIn this exporter plugin there is a onSyncTimeout call, as there is a onExportTimeout.07:32
chriadamand each time its "privileged to non-privileged" sync process finishes, it is triggering the syncTrigger (to export changes to sync plugins)07:32
dcalisteThis exporter plugin is doing the two things from what I understand from the code.07:32
chriadamyou're right07:33
chriadamyes, its scheduleSync() method is the problem07:33
dcalisteOn each modification, it is calling scheduleSync(), that fire both timeouts.07:33
dcalisteSo my best guess is that carddav is triggering a false modification which is creating a loop.07:34
dcalisteSadly the reporter scratched it's DB.07:34
dcalisteSo there is no reproducer available, only buteos logs.07:34
chriadam(it might not have been carddav, e.g. it could have been some third party app which writes to non-privileged database, e.g. some android app or something)07:34
dcalisteAh, I see your point.07:35
chriadamwell, two possibilities that I see:07:35
chriadam1) carddav sync failure is somehow still sending QContactManager signals even though the transaction fails/rollback07:35
chriadam2) carddav is merely being triggered each time, but the "actual" cause is the non-privileged to privileged sync causing endless sync cycle loop, which as side-effect triggers carddav sync07:36
chriadammy bets would be on (2) because of the fragility of that non-privileged to privileged etc code.07:36
chriadambut I may be wrong, and (1) may be the case07:36
dcalisteI think your 2) is more probable. Particularly after I quickly looked yesterday at the carddav logs and couldn't fine any debug messages dealing with modifications. The failure appended after the delta calculation after downloading the upstream changes but before applying them, as far as I can see. I don't know carddav code at all.07:37
chriadamall that sync code will change when we update qtpim and fix the addressbook separation issues.  coming soon tm.07:38
dcalisteI will try to investigate possible endless loop in the export part of the plugin, by triggering a change in the non priv db that cannot be commited or something similar.07:39
chriadamthanks very much.  fwiw I'd just suggest to the user if they hit the issue again, to do: dconf write /org/nemomobile/contacts/export/disabled 107:40
dcalisteYes, I wanted to tell him this also, but he scratched the db before I could ;)07:40
chriadamwell, I don't blame him07:41
chriadamhis device might have been about to catch fire07:42
dcalisteOf course, otherwise he killed the battery within hours.07:42
dcalisteAbout pending MR, I thank Blam again for her Help on the ContextMenu dynamic changes. The MR on keeping existing remainder time is much cleaner now, without using private properties anymore.07:44
dcalisteStill remains the oddity for the user to see remainder values for some entries that don't appears for others, but … no idea for this.07:45
dcalisteMay be solved later on when we add UI for arbitrary values.07:45
chriadamarbitrary value selector makes most sense to me, but let's see what MartinS thinks when the time comes.  for now, fine to have it this way I think07:46
dcalisteBut this by itself requires some design brainstorm on how to enter an arbitrary duration and an arbitrary unit.07:46
dcalisteSure Martin could help on this. We can wait for him to enjoy his vacations ;)07:47
chriadamyup, design work always takes time and iteration and testing / user feedback07:47
dcalisteWell, thank you chriadam for the discussion today and the idea about the non-priv to priv possible failure.07:49
chriadamthank you for your time and efforts as always!07:49
dcalisteI'll try to look closer in that direction, but without reproducer or even log in that domain, it may be unsuccessful. Let's see.07:49
chriadamas mentioned, contact sync stuff is likely to change significantly in the near future, and not sure what the end result will be for the non-privileged database (it might not exist at all, let's see..)07:50
chriadamso if it proves super tricky to reproduce, bear in mind that the whole lot might vanish in a few months07:50
chriadamyes, without repro it becomes very hard :-(07:50
chriadamif nothing else to discuss, have a great week07:51
chriadamand thanks again for your efforts, much appreciated07:51
dcalisteSure, I won't spend too much time if I cannot find anything solid. It's good anyway that this is being actively worked on from your side, I didn't have the problem but there are some reports about contactsd eating battery.07:52
dcalisteHave a nice week too.07:52
chriadamyeah, lots of contact sync things should hopefully be solved in the nearish future once we update things.07:53
chriadamrelated note: that carddav sync shouldn't have failed anyway, so even if it isn't the root cause of the issue that community member saw, it is still a problem that sync couldn't recover07:54
chriadamI will take a look also if I get a chance07:54
chriadamprobably something inside twowaycontactsyncadaptor in qtcontacts-sqlite07:54
chriadamanyway, I gotta head off - gnight! :-)07:55
kalipus8just got a nice xperia 1013:18
kalipus8but it has already been upgraded to android 1013:18
kalipus8so, do i have to downgrade it or can i use the sony android 10 asop kernel?13:19
*** kalipus8 is now known as kalipus15:14
*** Ischwitch is now known as Ingvix23:10

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