Tuesday, 2019-03-12

*** SpeedEvil is now known as Guest8145801:36
*** zbenjamin is now known as Guest3556702:40
*** zbenjamin_ is now known as zbenjamin02:40
*** frinring_ is now known as frinring05:26
*** rasva_ is now known as rasva07:30
dcalisteHello chriadam and jpetrell!08:01
chriadamhi dcaliste08:02
dcalisteLet start with the QtDeclarative bug, if you don't mind: I've updated the MR, using SurfaceAboutToBeDestroyed instead of hijacking Close.08:02
chriadamlet me check08:03
dcalisteFrom my tests, it's not breaking the day to day usage of the UI, luckily ;)08:03
dcalisteI didn't have time to check in depth that it's working for the lipstick-security-ui issue, but it seems so from some quick tries.08:04
dcalisteI've updated the MR in MER also: https://git.merproject.org/mer-core/qtdeclarative/merge_requests/2508:04
chriadamok.  I see Shawn has +1 it, I guess I just need to poke Laszlo to +2 it08:04
dcalisteAnd upstream: https://codereview.qt-project.org/#/c/253820/ (fro reference)08:05
dcalistechriadam: yes, thanks08:05
dcalisteI would suggest to merge and tag the MER side soon, if possible, so it can be tested early in the release schedule, in case…08:06
dcalisteI mean, it's touching every Quick Window after all…08:06
dcalisteAs I said, I'm using the patched Qt5Quick.so lib for more than a week now, and I didn't notice anything strange.08:07
chriadamAndrew seems fine with it also, so I will try to get that integrated asap08:08
dcalisteGreat, thank you.08:08
dcalisteDevelopping the SurfaceAboutToBeDestroyed version of the patch made me fall down on the timeout bug in Secret… (you know, reading debug logs for minutes while the UI is waiting…)08:10
dcalisteThe quick and dirty way of making the bug not appearing for sure is to decrease the 5min time in the password plugin to 2 minutes.08:11
dcalisteSince the manager as a 3 minutes timeout.08:11
chriadamI'm kind of leaning toward just defining some default timeout period somewhere, and using that same timeout everywhere.  e.g. 5 minutes.08:12
chriadambut I do think that having client-controllable timeout would be useful (so long as it's less than that maximum timeout)08:12
dcalisteMostly, I agree with this.08:13
chriadamon the daemon side, I'm pretty sure we track client disconnections.  do we need also some way to track "request cancellations"?08:14
dcalisteExcept that, (I don't know if you had time to read my long prose in https://github.com/sailfishos/sailfish-secrets/pull/156), there could still have the bug appearing if operation time become significant and is spent before the user interaction.08:14
dcalisteAh, you read it, nice ;)08:14
dcalisteOk, so I'm going to try to find where the daemon tracks the disconnection and see if we can notify the authentication plugin to call 'cancel' on the UI.08:16
chriadamlet me quickly grep08:18
dcalisteLet's do things like that for the moment: keep manager timeout to 3 minutes and decrease password plugin timeout to 2.5 minutes in a quick and dirty MR to patch the issue. And investigate how to notify the authentication plugins to cancel operations in a later MR.08:18
chriadamsounds good to me08:19
chriadammy quick grepping couldn't find any handling of client disconnection, funnily enough.  major oversight.08:20
dcalisteOk, I'll look for it this week and in case it's missing try to add it (properly: DBus is still foggy things for me).08:21
chriadamdcaliste: in the client side, we handle being forcibly disconnected from the server08:22
chriadamsee e.g. lib/Secrets/secretsdaemonconnection.cpp where we connect to the "Disconnected" signal08:23
chriadamin server side, however, we handle client connections: https://github.com/sailfishos/sailfish-secrets/blob/master/daemon/controller.cpp#L266 but not disconnections08:24
dcalisteAh, nice, thanks for the pointers. I can go quicker like that.08:25
dcalisteGoing from Secret to key management, did jpetrell or you have time to look at TJC wiki I started yesterday https://together.jolla.com/question/201406/community-contributions-for-personnal-key-management/ ?08:27
dcalisteI know it was short notice, so no problem if you hadn't ;)08:28
chriadamI had a look08:28
chriadamI think it needs a "Summary: We want feedback from people: 1) what key management features are vital for you, 2) what UI do you use in your OS (provide screen shots if possible)" sort of thing08:29
dcalisteIn my opinion, the target would be to build mockups of what should be displayed and in which context (setting page, or email detail page).08:30
chriadamcurrently it's hard to understand immediately what the goal is, I think08:30
dcalisteAh, you're right, I'll add an abstract.08:30
chriadamaside from that, looks good to me - but will need jpetrell to provide opinion too before we open it up, I guess08:30
dcalisteExplain the goal and the purpose of review of existing UIs.08:31
dcalisteSure, I'll wait for jpetrell approval also.08:31
chriadamhave you seen the existing key management UI in jolla-settings?  i.e. the sailfish-secrets-ui package content?08:31
dcalisteyes, I've installed it and I'm using it to check GnuPG implementation.08:32
dcalisteI was a bit disappointed it was not released Open sourced…08:32
chriadamso might be an idea to include screenshots of that as a "here's a super basic example of a UI implementation.  how could this be extended/improved?" to provide a concrete start-point for discussion08:32
chriadamdcaliste: I don't understand that bit either.08:33
dcalisteBut definitely, key management requires to have QML components that can be used in various places, emails, documents and settings.08:33
chriadambut I will raise that topic with jpetrell again also.  we need to polish it a lot anyway, we know, just haven't had chance yet..08:33
chriadamso maybe if we get a paying project to polish that, we can opensource as part of that activity -- worth asking management about again, anyway...08:34
dcalisteWell, opening it _without_ paying project would help to have it improved. I'm not much eager to write close source lines on my free time ;) As minimum as I can I would say !08:35
chriadamI completely agree.  but from our side, management won't approve largish work (like the polishing of the components) currently without a paying project, most likely.08:37
chriadambut that's a good point: community members could do such polishing if it were opened08:38
chriadamanyway, somethign for me to discuss with jpetrell and veskuh later08:38
dcalisteYes exactly my point, it can be a community driven effort, with just review from Jolla side. But before, let see if we can get some traction from other community members from the TJC pages for mockups and so on.08:38
chriadamon the email PRs side, I unfortunately still didn't get a chance to test the updated ones on device08:39
chriadamI was meant to yesterday, but ran out of time :-(08:40
chriadamon the IMAP IDLE side, I haven't heard back from anyone on Qt side08:41
chriadamshould I use the sledgehammer solution and just disable QMF builds in Qt CI for Mac OS X currently?08:41
chriadam(I'd prefer not to, obviously, but I don't have any better solution currently...)08:41
dcalisteI would say yes. Anyway, for the moment, we don't care about MacOS platform.08:41
chriadamindeed.  I will create that PR now08:41
dcalisteEven, if I'm convinced that it's a config issue. It's working on the MacOS 10.12 slave…08:42
chriadamyeah.  and a colleague of mine tested on an older 10.10 machine and it worked there too with Qt 5.9.708:42
dcalisteThere are many lines in common.pri related to MacOS platform, but I cannot figure out they are related to moc not being detected properly.08:42
dcalisteAnd it was working before on the same 10.13 slave, so it's a config issue.08:43
dcalisteBut from which setting, hard to say without access to the slave itself…08:43
karry_dcaliste: can you provide link to failing build please?08:44
dcalisteAh, and last but not least, moc is detected properly during the build process, _but_ not during the testing one…08:44
chriadamkarry_: https://codereview.qt-project.org/#/c/254084/08:44
dcalistekarry_: let me check…08:44
dcalistekarry_ and from coin: https://testresults.qt.io/coin/integration/qt-labs/messagingframework/tasks/155183806408:45
dcalistekarry: the build part is working properly, see https://testresults.qt.io/coin/api/results/qt-labs/messagingframework/7cb54ff44c53375e7fd952c74e835b8e12591c45/MacOSMacOS_10_13x86_64MacOSMacOS_10_13x86_64Clangqtci-macos-10.13-x86_64-2-ce09bfDebugAndRelease_Release/4bd042ef215c95e0aa4734a72a774e03f5182b5a/build_1551838145/log.txt.gz08:46
dcalisteBut the test part is failing while compiling test executables because qmake created calls to moc_wrapper.sh instead of moc itself, but moc_wrapper.sh was not packaged from the build process: https://testresults.qt.io/coin/api/results/qt-labs/messagingframework/7cb54ff44c53375e7fd952c74e835b8e12591c45/MacOSMacOS_10_13x86_64MacOSMacOS_10_13x86_64Clangqtci-macos-10.13-x86_64-2-ce09bfDebugAndRelease_Release/4bd042ef215c95e0aa4734a72a774e03f5182b5a/b08:47
dcalisteArg, wrong second link: https://testresults.qt.io/coin/api/results/qt-labs/messagingframework/7cb54ff44c53375e7fd952c74e835b8e12591c45/MacOSMacOS_10_13x86_64MacOSMacOS_10_13x86_64Clangqtci-macos-10.13-x86_64-2-ce09bfDebugAndRelease_Release/4bd042ef215c95e0aa4734a72a774e03f5182b5a/test_1551838146/log.txt.gz08:49
karry_thanks. I have no idea after fast look to the logs...08:52
chriadamseems like requires(!mac) should work08:54
chriadammy grep fu is weak, but finally `find . -type f -name "*pro"  -exec grep requires "{}" \; | grep mac` got some results08:54
chriadam... or should it be macx08:59
chriadammacx is used as a config in qtmultimedia, for example08:59
dcalisteYes, I think a !require(macx) in messagingframework.pro should work…08:59
dcalistesee common.pri in root.08:59
dcalistekarry_: thanks for caring anyway ;)09:00
dcaliste(forgot an 's' in requires)09:00
chriadamheck, will try to remove all three.  tor arne can let us know which is correct :-P09:02
dcalisteOk, let's try, and then the IMAP part can go in and ApBBB (and others) will be happy that IMAP can reconnect automatically after disconnection, thanks to flypig work.09:04
chriadamdefinitely good that that was been fixed.  and thank you for your work and help there too09:05
chriadamI guess jpetrell is not in the office yet/today09:06
chriadamI will follow up regarding the tjc iwki09:06
chriadamand also the signing prs etc09:07
dcalisteand the QtDeclarative bug (MER side and upstream), if I may add ;)09:07
chriadamyep.  I poked laszlo about that upstream one09:08
dcalisteBut yeh, thanks already !09:08
dcalisteRegarding QtDeclarative, there is still a bug, not crashing one that appears even less often about some ticking timer that sometimes kept ticking after window destruction.09:09
dcalisteI'm going to investigate further, I'm afraid it may eat battery otherwise. But that's not correlated and that's for later.09:10
chriadamI will ask Andrew if he has any ideas09:11
chriadamthanks for that09:11
chriadamis it that there are timer events being delivered within the event loop?  or is it something wakelock related?09:12
dcalisteIt's the tick in qsgthreadedrenderloop.cpp:124109:14
dcalisteIf you run with full debug, very rarely, it happens that this event is still delivered, even after window destruction.09:15
dcalisteIt fills up the debug log with this print line.09:15
dcalisteSo, there is a race condition that makes this timer not stopped on destruction.09:15
dcalisteNeed to find it.09:15
chriadamthanks, I've passed that on to Andrew.  he might be able to point directly at it, let's see.09:16
dcalisteI've seen it since a long time debugging the close issue, but I put it aside, prioritizing the crashing bug.09:16
dcalisteBut thanks to discuss it with Andrew.09:16
chriadamcrashing is definitely higher priority :-D09:17
chriadamanyway, thank you again for your work and help.  it is greatly appreciated.  again sorry that we are sometimes so slow here.09:17
chriadamanyway, I had nothing else to discuss, and seems like Joona is not in the office today so not sure about Sailfish Office progress / things.09:18
chriadamdid you have anything further to discuss?09:18
dcalisteNo problem, I understand Jolla is running business in difficult context, so don't have the same timeframe as hobby developer ;)09:18
dcalisteI think we addressed all the points I wanted to discuss today. Thanks for this fruitfull discussion.09:18
chriadamgreat, thank you!09:19
chriadamoh, did any other community contributors have anything they wanted to discuss?09:19
chriadam(if not, I will be leaving office within 15 mins or so, but feel free to ping me now or at any time for such discussion / planning / requests etc)09:19
dcalisteThank you chriadam for giving from your time to community also!09:20
*** sledges_ is now known as sledges10:20
*** Guest9662 is now known as Helle11:56
*** BitEvil is now known as SpeedEvil13:19
*** Helle is now known as Guest822016:13
*** Guest8220 is now known as Helle17:45

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