| *** SpeedEvil is now known as Guest81458 | 01:36 | |
| *** zbenjamin is now known as Guest35567 | 02:40 | |
| *** zbenjamin_ is now known as zbenjamin | 02:40 | |
| *** frinring_ is now known as frinring | 05:26 | |
| *** rasva_ is now known as rasva | 07:30 | |
| dcaliste | Hello chriadam and jpetrell! | 08:01 |
|---|---|---|
| chriadam | hi dcaliste | 08:02 |
| dcaliste | Let start with the QtDeclarative bug, if you don't mind: I've updated the MR, using SurfaceAboutToBeDestroyed instead of hijacking Close. | 08:02 |
| chriadam | let me check | 08:03 |
| dcaliste | From my tests, it's not breaking the day to day usage of the UI, luckily ;) | 08:03 |
| dcaliste | I 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 |
| dcaliste | I've updated the MR in MER also: https://git.merproject.org/mer-core/qtdeclarative/merge_requests/25 | 08:04 |
| chriadam | ok. I see Shawn has +1 it, I guess I just need to poke Laszlo to +2 it | 08:04 |
| dcaliste | And upstream: https://codereview.qt-project.org/#/c/253820/ (fro reference) | 08:05 |
| dcaliste | chriadam: yes, thanks | 08:05 |
| dcaliste | I 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 |
| dcaliste | I mean, it's touching every Quick Window after all… | 08:06 |
| chriadam | indeed... | 08:06 |
| dcaliste | As 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 |
| chriadam | great | 08:08 |
| chriadam | Andrew seems fine with it also, so I will try to get that integrated asap | 08:08 |
| dcaliste | Great, thank you. | 08:08 |
| dcaliste | Developping 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 |
| dcaliste | The 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 |
| dcaliste | Since the manager as a 3 minutes timeout. | 08:11 |
| chriadam | I'm kind of leaning toward just defining some default timeout period somewhere, and using that same timeout everywhere. e.g. 5 minutes. | 08:12 |
| chriadam | but I do think that having client-controllable timeout would be useful (so long as it's less than that maximum timeout) | 08:12 |
| dcaliste | Mostly, I agree with this. | 08:13 |
| chriadam | on the daemon side, I'm pretty sure we track client disconnections. do we need also some way to track "request cancellations"? | 08:14 |
| dcaliste | Except 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 |
| dcaliste | Ah, you read it, nice ;) | 08:14 |
| dcaliste | Ok, 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 |
| chriadam | let me quickly grep | 08:18 |
| dcaliste | Let'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 |
| chriadam | sounds good to me | 08:19 |
| chriadam | my quick grepping couldn't find any handling of client disconnection, funnily enough. major oversight. | 08:20 |
| dcaliste | Ok, 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 |
| chriadam | dcaliste: in the client side, we handle being forcibly disconnected from the server | 08:22 |
| chriadam | see e.g. lib/Secrets/secretsdaemonconnection.cpp where we connect to the "Disconnected" signal | 08:23 |
| chriadam | in server side, however, we handle client connections: https://github.com/sailfishos/sailfish-secrets/blob/master/daemon/controller.cpp#L266 but not disconnections | 08:24 |
| dcaliste | Ah, nice, thanks for the pointers. I can go quicker like that. | 08:25 |
| dcaliste | Going 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 |
| dcaliste | I know it was short notice, so no problem if you hadn't ;) | 08:28 |
| chriadam | I had a look | 08:28 |
| chriadam | I 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 thing | 08:29 |
| dcaliste | In 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 |
| chriadam | currently it's hard to understand immediately what the goal is, I think | 08:30 |
| chriadam | right | 08:30 |
| dcaliste | Ah, you're right, I'll add an abstract. | 08:30 |
| chriadam | aside from that, looks good to me - but will need jpetrell to provide opinion too before we open it up, I guess | 08:30 |
| dcaliste | Explain the goal and the purpose of review of existing UIs. | 08:31 |
| dcaliste | Sure, I'll wait for jpetrell approval also. | 08:31 |
| chriadam | have you seen the existing key management UI in jolla-settings? i.e. the sailfish-secrets-ui package content? | 08:31 |
| dcaliste | yes, I've installed it and I'm using it to check GnuPG implementation. | 08:32 |
| dcaliste | I was a bit disappointed it was not released Open sourced… | 08:32 |
| chriadam | so 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 discussion | 08:32 |
| chriadam | dcaliste: I don't understand that bit either. | 08:33 |
| dcaliste | But definitely, key management requires to have QML components that can be used in various places, emails, documents and settings. | 08:33 |
| chriadam | but 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 |
| chriadam | so 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 |
| dcaliste | Well, 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 |
| chriadam | I 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 |
| chriadam | but that's a good point: community members could do such polishing if it were opened | 08:38 |
| chriadam | anyway, somethign for me to discuss with jpetrell and veskuh later | 08:38 |
| dcaliste | Yes 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 |
| chriadam | ye | 08:38 |
| chriadam | on the email PRs side, I unfortunately still didn't get a chance to test the updated ones on device | 08:39 |
| chriadam | I was meant to yesterday, but ran out of time :-( | 08:40 |
| chriadam | on the IMAP IDLE side, I haven't heard back from anyone on Qt side | 08:41 |
| chriadam | should 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 |
| dcaliste | I would say yes. Anyway, for the moment, we don't care about MacOS platform. | 08:41 |
| chriadam | indeed. I will create that PR now | 08:41 |
| dcaliste | Even, if I'm convinced that it's a config issue. It's working on the MacOS 10.12 slave… | 08:42 |
| chriadam | yeah. and a colleague of mine tested on an older 10.10 machine and it worked there too with Qt 5.9.7 | 08:42 |
| dcaliste | There 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 |
| dcaliste | And it was working before on the same 10.13 slave, so it's a config issue. | 08:43 |
| dcaliste | But 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 |
| dcaliste | Ah, and last but not least, moc is detected properly during the build process, _but_ not during the testing one… | 08:44 |
| chriadam | karry_: https://codereview.qt-project.org/#/c/254084/ | 08:44 |
| dcaliste | karry_: let me check… | 08:44 |
| dcaliste | karry_ and from coin: https://testresults.qt.io/coin/integration/qt-labs/messagingframework/tasks/1551838064 | 08:45 |
| dcaliste | karry: 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.gz | 08:46 |
| dcaliste | But 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/b | 08:47 |
| dcaliste | uild_1551838145/log.txt.gz | 08:47 |
| dcaliste | Arg, 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.gz | 08:49 |
| karry_ | thanks. I have no idea after fast look to the logs... | 08:52 |
| chriadam | seems like requires(!mac) should work | 08:54 |
| chriadam | my grep fu is weak, but finally `find . -type f -name "*pro" -exec grep requires "{}" \; | grep mac` got some results | 08:54 |
| chriadam | ... or should it be macx | 08:59 |
| chriadam | macx is used as a config in qtmultimedia, for example | 08:59 |
| chriadam | hrm. | 08:59 |
| dcaliste | Yes, I think a !require(macx) in messagingframework.pro should work… | 08:59 |
| dcaliste | see common.pri in root. | 08:59 |
| dcaliste | karry_: thanks for caring anyway ;) | 09:00 |
| dcaliste | (forgot an 's' in requires) | 09:00 |
| chriadam | heck, will try to remove all three. tor arne can let us know which is correct :-P | 09:02 |
| dcaliste | Ok, 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 |
| chriadam | definitely good that that was been fixed. and thank you for your work and help there too | 09:05 |
| chriadam | I guess jpetrell is not in the office yet/today | 09:06 |
| chriadam | I will follow up regarding the tjc iwki | 09:06 |
| chriadam | and also the signing prs etc | 09:07 |
| dcaliste | and the QtDeclarative bug (MER side and upstream), if I may add ;) | 09:07 |
| chriadam | yep. I poked laszlo about that upstream one | 09:08 |
| dcaliste | But yeh, thanks already ! | 09:08 |
| dcaliste | Regarding 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 |
| dcaliste | I'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 |
| chriadam | I will ask Andrew if he has any ideas | 09:11 |
| chriadam | thanks for that | 09:11 |
| chriadam | is it that there are timer events being delivered within the event loop? or is it something wakelock related? | 09:12 |
| dcaliste | It's the tick in qsgthreadedrenderloop.cpp:1241 | 09:14 |
| chriadam | ah! | 09:14 |
| chriadam | interesting | 09:14 |
| dcaliste | If you run with full debug, very rarely, it happens that this event is still delivered, even after window destruction. | 09:15 |
| dcaliste | It fills up the debug log with this print line. | 09:15 |
| dcaliste | So, there is a race condition that makes this timer not stopped on destruction. | 09:15 |
| dcaliste | Need to find it. | 09:15 |
| chriadam | thanks, I've passed that on to Andrew. he might be able to point directly at it, let's see. | 09:16 |
| dcaliste | I've seen it since a long time debugging the close issue, but I put it aside, prioritizing the crashing bug. | 09:16 |
| dcaliste | But thanks to discuss it with Andrew. | 09:16 |
| chriadam | crashing is definitely higher priority :-D | 09:17 |
| chriadam | anyway, thank you again for your work and help. it is greatly appreciated. again sorry that we are sometimes so slow here. | 09:17 |
| chriadam | anyway, 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 |
| chriadam | did you have anything further to discuss? | 09:18 |
| dcaliste | No problem, I understand Jolla is running business in difficult context, so don't have the same timeframe as hobby developer ;) | 09:18 |
| dcaliste | I think we addressed all the points I wanted to discuss today. Thanks for this fruitfull discussion. | 09:18 |
| chriadam | great, thank you! | 09:19 |
| chriadam | oh, 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 |
| dcaliste | Thank you chriadam for giving from your time to community also! | 09:20 |
| *** sledges_ is now known as sledges | 10:20 | |
| *** Guest9662 is now known as Helle | 11:56 | |
| *** BitEvil is now known as SpeedEvil | 13:19 | |
| *** Helle is now known as Guest8220 | 16:13 | |
| *** Guest8220 is now known as Helle | 17:45 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!