| *** zbenjamin_ is now known as zbenjamin | 02:44 | |
| *** feodoran is now known as Guest41596 | 03:36 | |
| *** feodoran_ is now known as feodoran | 03:36 | |
| *** frinring_ is now known as frinring | 06:19 | |
| dcaliste | Hello chriadam and jpetrell. | 08:10 |
|---|---|---|
| chriadam | dcaliste: hi :-) | 08:10 |
| chriadam | jpetrell is not in the office currently, he said he will be in around midday due to some personal things he has to do in the morning | 08:11 |
| dcaliste | I've seen your remarks on email settings. | 08:12 |
| dcaliste | I'm addressing the issue when creating a new account. | 08:12 |
| chriadam | aside from that it's looking great. I haven't yet tested generating a GPG key on device (currently I just imported a key I generated elsewhere) but will test that next | 08:13 |
| chriadam | but once you fix that issue I noted, I will approve and merge/tag unless jpetrell or pvuorela say otherwise, either tomorrow or thursday | 08:14 |
| chriadam | also, just asked internally about the pkcon refresh / version --dup issue. thanks for the extra info there, hopefully someone like pketo can shed light.. | 08:14 |
| dcaliste | During account creation, the email is not available (from settings), so the crypto section should not be displayed. Do you agree ? | 08:18 |
| dcaliste | This key setting can be selected later, or is it misleading not to have it at account creation, and have it appearing later? | 08:19 |
| chriadam | you mean, it cannot lookup the email address from the account settings yet, to know which keys could be associated with it? | 08:20 |
| dcaliste | This is linked to the root.!isNewAccount {populateServiceSettings() } in EmailSettingsDisplay.qml | 08:20 |
| chriadam | I think it is definitely better to have it settable immediately during account creation, rather than requiring backstep+forwardstep (from design perspective). but perhaps it's not possible? | 08:21 |
| dcaliste | The key section is using the email address to propose available keys. | 08:21 |
| dcaliste | I agree with the fact that it's better to be able to set at account creation. | 08:21 |
| Coolgeek | maybe another page to allow key generation after setting up the mail | 08:21 |
| dcaliste | I need to find how to get the email address at that time, because I guess it's not yet available in service settings. | 08:22 |
| satmd | hello world | 08:23 |
| chriadam | an intermezzo page is definitely one solution. but maybe you can somehow pass the value through to the lookup method instead of requiring it to be read from the settings (which wouldn't yet exist in that case) | 08:23 |
| chriadam | hello satmd | 08:23 |
| dcaliste | chriadam: yes, I agree, I'm testing the creation flow currently (I didn't look at it for a long time) and I will see how to get the email address. It should be present definitely. | 08:25 |
| dcaliste | In fact, it exists already, because the fullName variable is set initially with the email from the settings. So ok, I'll find a way to get it. | 08:27 |
| chriadam | great! | 08:27 |
| dcaliste | I will submit a patch later today. | 08:27 |
| chriadam | thanks very much | 08:27 |
| dcaliste | What about the IDLE upstream MR ? | 08:27 |
| chriadam | on QMF side, the IDLE patch merged upstram I believe | 08:27 |
| dcaliste | Yes | 08:28 |
| chriadam | so on Mer side do we just need to merge https://git.merproject.org/mer-core/messagingframework/merge_requests/30 ? | 08:28 |
| pvuorela | this still open? https://codereview.qt-project.org/#/c/255086/ | 08:29 |
| dcaliste | Yes, but it's still WIP, because I need the sha of the upstream HEAD. | 08:29 |
| chriadam | oh, not merged yet | 08:29 |
| dcaliste | pvuorela, yes this one. | 08:29 |
| chriadam | oops | 08:29 |
| chriadam | well, I will poke Matt again on Thursday.. | 08:29 |
| dcaliste | Ok, thanks, when it's accepted upstream, I can update MR!30 on MER side with the right sha. | 08:30 |
| chriadam | pvuorela: have you reviewed that one yet? I guess it's all code which was previously accepted into Mer QMF, right? | 08:30 |
| dcaliste | chriadam: I think flypig has also tested on device this MER+upstream patches. | 08:31 |
| chriadam | in any event I will review it tomorrow and then on Thursday poke Matt. If he doesn't have time spare to review, I will +2 it and we'll get it in, unless pvuorela has concerns. | 08:31 |
| chriadam | yep, saw that he had tested it, in the bug report | 08:31 |
| dcaliste | Ok, good. Thank you. | 08:32 |
| pvuorela | chriadam: have checked and seemed good to me, though would be nice if matt or someone could approve too :) | 08:32 |
| chriadam | indeed. thanks | 08:33 |
| pvuorela | set +1 for now. | 08:33 |
| dcaliste | chriadam: I've also continued to work on the cancellation API for user input request in secrets. But MR is not ready yet. I'm implementing in the inapp plugin at the moment. Then still remains the daemon part, as we discussed last Thursday. | 08:34 |
| chriadam | yes, most likely some complexity there | 08:35 |
| chriadam | I didn't review the updated PR to secrets side with the timeout fix yet, either | 08:35 |
| dcaliste | Well, I've changed back to just adjust the timeout in the password plugin to make it lower than the manager timeout. It's a one liner if I remember, beside the added comment. | 08:36 |
| chriadam | sounds simple enough ;-) | 08:37 |
| dcaliste | The real solution for this will be the cancellation mechanism that will ensure that password dialog is withdraw when the manager stops the connection. | 08:37 |
| chriadam | indeed | 08:37 |
| dcaliste | The timeout parameter in the request would be a nice addition, but I postponed it for after the cancellation issue solution. | 08:37 |
| dcaliste | Because it's not solving the issue by itself in fact. | 08:38 |
| chriadam | I agree | 08:40 |
| dcaliste | I'm also trying to figure out this CalDAV issue: https://together.jolla.com/question/201611/caldav-calendar-msyncd-fails-when-updating-event-with-exceptions | 08:40 |
| dcaliste | The user kindly sent me a huge part of the logs and many things are broken. | 08:41 |
| dcaliste | I'm going to ask him today some data from the Calendar database. | 08:41 |
| chriadam | ouch | 08:42 |
| dcaliste | Because, currently, after delta calculation, some events with the same UID are listed both in local modifications and remote ones. | 08:42 |
| chriadam | meanwhile, I'm fixing a bunch of carddav issues. I'll have a PR for review in... hopefully 10 mins | 08:42 |
| dcaliste | And from the subsequent PUT request, it seems that exceptions of a given event don't have the same etag as the main event… | 08:43 |
| chriadam | hmm, I thought our conflict resolution strategy (always prefer server-side changes) would eliminate that case | 08:43 |
| chriadam | ouch... ok... that's scary | 08:43 |
| chriadam | different calendars perhaps? same UID? | 08:43 |
| dcaliste | Finally, the PUT request is failing miserably because the IF-Match is done with an etag from one of the exception (it seems). | 08:43 |
| dcaliste | The annoying thing is that it's failing even after a slowSync for a new account. | 08:44 |
| chriadam | well, something's clearly wrong then :-P | 08:45 |
| dcaliste | I will ask him result of things like "SELECT comments, uid from Components" to have an idea how the database is looking. Because currently I have no idea how delta calculation can put same UID both remote and local mods. | 08:45 |
| chriadam | yeah | 08:45 |
| dcaliste | So just to keep you up-to-date on this. I'll fill a bug as soon as I understand the root of the issue. Hoepfully later this week. | 08:47 |
| dcaliste | But currently I'm in a complete fog… | 08:47 |
| chriadam | thanks very much | 08:47 |
| dcaliste | The guy is very helpful and responsive so I hope I can figure out what's happening. | 08:48 |
| chriadam | that's great. glad that the sfos community is so patient and willing to help. | 08:49 |
| chriadam | dcaliste: https://git.merproject.org/mer-core/buteo-sync-plugin-carddav/merge_requests/19 but I need to do some final testing first | 08:51 |
| dcaliste | chriadam: ok, I 'll give a look later today. But I'm not (yet?) using any carddav synchronisation, but I can comment on code (at my level). | 08:54 |
| chriadam | of course, no worries :-) | 08:54 |
| chriadam | at some point, it would be nice if we could merge the mostly common parts of the carddav+caldav plugins (e.g. generic dav handling), but that will have to wait until we support properly-separated-addressbooks in QtPIM in sfos | 08:55 |
| chriadam | your webdav plugin probably did most of that already I guess (splitting out dav stuff) | 08:56 |
| dcaliste | I still have a branch with reworked notebooksyncagent.cpp and incidencehandler.cppp from caldav, so dav things are separated from synchronisation machinery. But I need to find time to check that it's safe to make the switch otherwise many peolple will not be happy if I break something client side for code beautification reasons ;) | 08:58 |
| chriadam | yeah. one day we need to spend some serious engineering effort on refactoring various middleware pieces in general (e.g. buteo etc). hopefully one day we will have more resources internally to spend on such activity | 08:59 |
| chriadam | anyway, I didn't have anything further to discuss. I don't think jpetrell yet had time to look at the tjc wiki about key handling, unfortunately. | 09:01 |
| chriadam | if anyone else has discussion topics / questions, please feel free to chime in. I'll be here for another 20 mins or so I guess anyway :-) | 09:01 |
| chriadam | once again, thanks for all of your hard work and effort, dcaliste. we definitely appreciate it. | 09:01 |
| chriadam | please poke me on Thursday if I've forgotten to merge the upstream qmf thing | 09:02 |
| dcaliste | Ah, yes, thanks to mention it, I forgot about it. Well, it's to prepare some work in advance anyway and I'm already much occupied. | 09:02 |
| chriadam | yep. I'll raise it with him internally again | 09:04 |
| dcaliste | Thanks. | 09:04 |
| chriadam | ok, I had nothing else. Have a great week :-) | 09:07 |
| feodoran | Is there something broken here (on 3.0.2.8)? `Problem: qt5-qtdeclarative-qmlscene-5.6.3+git5-1.4.2.jolla.armv7hl requires qt5-qtdeclarative = 5.6.3+git5-1.4.2.jolla, but this requirement cannot be provided` | 09:08 |
| dcaliste | feodoran: have you done `pkcon refresh` before ? | 09:10 |
| feodoran | yes | 09:11 |
| dcaliste | On device, I've versions tagged git5-1.4.3, while you have 1.4.2… | 09:13 |
| dcaliste | Thank you chriadam for the meeting today, have a nice evening. | 09:14 |
| feodoran | dcaliste: I have qt5-qtdeclarative-5.6.3+git5-1.4.3.jolla.armv7hl as well, but the problem is that qt5-qtdeclarative-qmlscene is 1.4.2, maybe the qmlscene package needs to be updated in the repo? | 09:15 |
| dcaliste | feodoran: well, 1.4.3 is available (for me) from repos, and `devel-su pkcon install qt5-qtdeclarative-qmlscene` is indeed returning `The following packages have to be installed: qt5-qtdeclarative-qmlscene-5.6.3+git5-1.4.3.jolla.armv7hlQML scene viewer` | 09:20 |
| chriadam | definitely try `devel-su pkcon refresh` again. I hit an issue related to that recently, pketo mentioned that the metadata cache for system updates is different to the "normal" cache. | 09:21 |
| feodoran | I tried pkcon refresh for the third time now ... still same error | 09:24 |
| dcaliste | So, for once, pkcon refresh may not be the reason ;) I'm wondering if repo package lists are exactly the same for early access and for internal Jolla or CBeta. pketo, if you have a moment to look for version available for qt5-qtdeclarative-qml-scene in EA repos, if it's indeed at git5-1.4.3 and not git5-1.4.2? | 09:27 |
| pketo | I'll take a look | 09:28 |
| dcaliste | pketo, thanks a lot. | 09:28 |
| pketo | qt5-qtdeclarative-qmlscene ver="5.6.3+git5" rel="1.4.3.jolla" | 09:33 |
| dcaliste | pketo, ok, thank you and sorry for the disturbance. feodoran, can you check if `ssu lr` is properly listing repo with 3.0.2.8 version in urls? | 09:34 |
| feodoran | dcaliste: no its 3.0.1.14, seems something went during upgrade ... | 09:35 |
| feodoran | how do I fix this? is there a way to check for further issues? | 09:36 |
| feodoran | *went wrong ... | 09:36 |
| dcaliste | feodoran, what is `ssu re` reporting ? | 09:37 |
| pketo | and how about `version` ? | 09:38 |
| feodoran | `Device release is currently: 3.0.1.14`, which is weird because in SFOS Settings-> Device Info it says 3.0.2.8 | 09:38 |
| feodoran | verions says 3.0.2.8 | 09:38 |
| pketo | ssu re 3.0.2.8 | 09:38 |
| pketo | pkcon refresh; pckon get-updates | 09:39 |
| feodoran | pckon get-updates outputs a couple of "Enhancement ..." lines | 09:40 |
| pketo | which packages? | 09:41 |
| feodoran | oh, wait I overlook `ssu re 3.0.2.8` | 09:41 |
| pketo | yes, that needs to be done first | 09:42 |
| feodoran | ok, now I get different Enhancements: aliendalvik, augeas-libs, droid-config, feature-jolla, ofono-ril-binder-plugin, sailfish-components-weather, zypper | 09:43 |
| pketo | ok, probably best to run version --dup | 09:44 |
| feodoran | is there a log of the first "upgrade" somewhere? to look what went wrong? | 09:46 |
| pketo | in /var/log/systemupdate.log | 09:46 |
| pketo | if you did that normally via UI | 09:47 |
| feodoran | `Mar 18 19:10:07 XA2 patchmanager[10555]: PatchManagerObject::requestCheckForUpdates()::__lambda217 Error: QNetworkReply::NetworkError(HostNotFoundError)` | 09:50 |
| feodoran | why network during the actual upgrade? | 09:50 |
| pketo | patchmanager maybe does something it shouldn't | 09:52 |
| feodoran | ok, upgrade seems fine now, thanks! | 09:58 |
| feodoran | `Mar 18 19:00:56 XA2 sailfish-upgrade-ui[2803]: Reverting the SSU version to 3.0.1.14` what? why? | 10:01 |
| feodoran | oh ... /opt ran out of space ... | 10:01 |
| *** SpeedEvil is now known as Guest17032 | 10:29 | |
| mal | feodoran: what does /opt contain on your device? | 10:41 |
| feodoran | mal: I was tinkering around with https://github.com/yeoldegrove/sailfish-signature-spoofing, and decided to keep the original /opt/alien/system.img as a backup in that same place, so it was basically my fault | 10:43 |
| mal | feodoran: ok, thought something odd had to be happening since that partition should basically only have the system.img | 10:45 |
| *** aivot-on_ is now known as aivot-on | 12:25 | |
| pvuorela | dcaliste: calligra-sheets.patch, you remember if there was any special reason to comment out d->locale? got some crash with xls file with null QLocale used that could be related. seems to compile without changes too. | 12:47 |
| dcaliste | pvuorela: I think I wanted to avoid deprecations, or warnings… I'm checking. | 12:49 |
| dcaliste | pvuorela: after checking, maybe a left over. Initially, I wanted to avoid as much as possible inserting headers from kde4libs the compatibility KF5 packages for deprecated calls. KLocale was deprecated and at first I guess I wanted to see if I can compile without. | 12:55 |
| dcaliste | After a while, I gave up and imported various headers with empty shell implementation for various kde4libs headers, like klocale.h | 12:56 |
| dcaliste | It seems that I forgot to remove the commenting of d->locale… | 12:56 |
| pvuorela | dcaliste: thanks for checking. was also assuming it could be such as localization.cpp is anyway build. | 12:56 |
| pvuorela | let's bring that part in then soonish. | 12:57 |
| dcaliste | Yeah, Localization.cpp being built is not an issue per se, but the fact that it inherit from KLocale whch is deprecated was annoying. Since I took the empty shell impl of klocale.h from leinir job, I think it's safe to use it properly and revert the commenting of d->locale. | 13:01 |
| pvuorela | there seems to be quite a collection of old cruft in calligra :/ | 13:06 |
| leinir | It comes from doing a massive porting effort at a time when KF5 was still in its infancy... Not really an excuse, more a reason ;) | 13:12 |
| *** BitEvil_ is now known as speedevil | 13:37 | |
| *** speedevil is now known as SpeedEvil | 13:39 | |
| dcaliste | pvuorela: yes, it would be nice contributions to remove deprecated kde4libs dependencies, but as you notice its a huge job, particularly in sheets. | 13:42 |
| fledermaus | hm. no maps. sad times. | 15:48 |
| fledermaus | anyone else on oulanka and have working maps? | 16:11 |
| *** Venemo_XA2 is now known as Venemo_XA2_ | 17:47 | |
| *** Venemo_XA2_ is now known as Venemo_XA2 | 17:47 | |
| kaol | I'm making an app. https://gitlab.com/piperka/client | 19:20 |
| Venemo_XA2 | cool, what does it do? | 19:24 |
| kaol | It's a web comic reader. | 19:25 |
| zebbiz_pi | kaol: Reader or tracker? | 19:34 |
| kaol | Both? I have a list of their archive pages that I use for embedding in a webview with navigation and I'm running a crawler to catch updates. | 19:36 |
| mcencora | hi. how do I rebuild given package with my patches? | 21:35 |
| Venemo_XA2 | mcencora: can you be more specific? | 21:49 |
| mcencora | Venomo_XA2: I am trying to narrow down high memory consumption issue with contactsd. with heaptrack I was also able to find a cause of a lot of unnecessary memory allocations | 22:00 |
| mcencora | I want to check if my fix will work | 22:00 |
| mcencora | so i need to rebuild contactsd package | 22:00 |
| mcencora | ^Venemo_XA2 | 22:01 |
| Venemo_XA2 | well, are you familiar with the platform sdk? | 22:28 |
| r0kk3rz | mcencora: imo build it on obs | 22:33 |
| mcencora | Venemo_XA2: nope, so far I have only used app sdk. thanks for pointing it out, I'll look into it. | 22:34 |
| mcencora | r0kk3rz: i have zero experience/knowledge with obs but i'll check it out as well | 22:36 |
| r0kk3rz | mcencora: you'll need a mer account if you want to submit your work anyway | 22:36 |
| Venemo_XA2 | mcencora: it's a bit complicated, and only works on linux. in fact the app dev sdk build machine also runs the platforms sdk, they just bundled it into a vm | 22:36 |
| Venemo_XA2 | possibly the app dev sdk could also do it though | 22:49 |
| Venemo_XA2 | mcencora: is there any place we can have a look at your patches? | 22:50 |
| mcencora | Venemo_XA2: nope, but FWIW the fixes are in dbIdToString functions - to avoid unnecessary allocations. file contactid.cpp | 22:52 |
| mcencora | I can prepare a patch tomorrow | 22:52 |
| Venemo_XA2 | feel free to ping us tomorrow mcencora | 22:53 |
| Venemo_XA2 | I'll try to bring this to the attention of the right people | 22:53 |
| mcencora | ok, thanks | 22:55 |
| Venemo_XA2 | good night! | 22:59 |
| r0kk3rz | mcencora: having the code on git.merproject.org is a good idea too | 23:08 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!