| *** keithzg__ is now known as keithzg_ | 00:01 | |
| *** zbenjamin is now known as Guest76125 | 01:16 | |
| *** zbenjamin_ is now known as zbenjamin | 01:16 | |
| dcaliste | Hello chriadam, how are you ? | 06:45 |
|---|---|---|
| chriadam | hi dcaliste, I'm well thanks! | 06:45 |
| chriadam | how are you? | 06:45 |
| dcaliste | Fine also thanks. I've looked at the upsyncing on change in jolla-calendar. | 06:46 |
| chriadam | ah nice, hopefully simple solution? | 06:47 |
| chriadam | seems fairly simple. the fact that it requests the profiles from the buteo profile manager, based on the accountId filter is interesting - I hope we set the accountId appropriately in all sync profiles | 06:52 |
| chriadam | thanks very much for doing that work. I don't think I'll get a chance to test it this week, but hopefully next week. | 06:52 |
| dcaliste | Sorry, got interrupted by a collegue in the lab… | 06:54 |
| dcaliste | well, see https://bitbucket.org/jolla/ui-jolla-calendar/pull-requests/228 | 06:54 |
| dcaliste | The trick, was that only the notebook id is available at nemo-qml-plugin-calendar, not the account id. | 06:55 |
| chriadam | indeed | 06:55 |
| dcaliste | So, I gather all the calendar ids, and accumulate them during the last ten seconds, like you did for changes. | 06:55 |
| dcaliste | And, when it's time to sync, I use some mKCal calls to get the account id from notebook ids. | 06:56 |
| dcaliste | That's a simple patch on existing solution. | 06:56 |
| dcaliste | To put it in Buteo, I've looked at it closely last week. | 06:56 |
| dcaliste | It's missing some bits in the current API, in my opinion. | 06:56 |
| dcaliste | As far as I can see, it's not used at the moment at all. It's implemented for hcontacts scheme only, but there is no plugin installed on device. | 06:58 |
| dcaliste | I can extend it for hcalendars, and create a plugin. | 06:58 |
| dcaliste | But… | 06:58 |
| dcaliste | This plugin will trigger changed() on every change in the mKCal database, without specifying from which notebook, and thus from which account it is originating. | 06:59 |
| chriadam | let's ignore it for now. in future, I really want to refactor buteo altogether | 06:59 |
| chriadam | and when we do that, we can make sure the interfaces allow the granularity we want | 06:59 |
| dcaliste | The idea is to add the accountId in the changed() signal. | 06:59 |
| chriadam | buteo makes me cringe whenever i look at it. architecture is quite good, IMO, but the implementation leaves a lot to be desired. | 06:59 |
| dcaliste | Ah, we can post pone also ;) | 06:59 |
| dcaliste | Exactly my feeling ! | 07:00 |
| dcaliste | I like the general idea, but graps my hair when looking at some implementation details. | 07:00 |
| chriadam | yeah. and we have just hacked stuff on top to get things working, which no doubt made the situation worse. | 07:01 |
| dcaliste | Do you think it's a waste of time to change the API of the SyncOnChange part ? | 07:01 |
| dcaliste | It would be nicer to have the sync on change bits in the daemon than in the app, no ? | 07:01 |
| chriadam | yes I completely agree. | 07:01 |
| chriadam | but there are some complexities | 07:02 |
| chriadam | e.g. in the future, we want to daemonise different APIs (e.g. contacts, calendar, accounts, etc) | 07:02 |
| chriadam | when we do that, each API will have an associated daemon | 07:02 |
| chriadam | and all client API calls will be via IPC (e.g. p2p dbus perhaps) | 07:02 |
| chriadam | so once we move to that architecture, it makes more sense to have e.g. the calendar daemon "listen" for changes and trigger appropriate syncs | 07:03 |
| chriadam | rather than msyncd itself | 07:03 |
| chriadam | (for access control reasons, we want to limit what msyncd could access, etc) | 07:03 |
| dcaliste | Ok, at least with the patch in calendar, Google won't sync when I modify some other calendar… | 07:04 |
| chriadam | indeed ;-) | 07:04 |
| dcaliste | Tell me when this work is started from Jolla side, I will be able to assist. | 07:04 |
| chriadam | unfortunately I don't expect that work to begin in the near future | 07:05 |
| chriadam | but will definitely keep you in the loop | 07:05 |
| dcaliste | Thanks. In the meantime, I can continue to separate mKCal backend from syncing logic in caldav plugin ;) | 07:06 |
| dcaliste | (And add task handling…) | 07:06 |
| chriadam | task handling? oh is this ToDo support? | 07:07 |
| dcaliste | Yep. | 07:07 |
| dcaliste | With the refactoring that will land as a MR shortly now, the code should be able to sync todos also. | 07:07 |
| chriadam | btw I merged the mkcal + caldav changes - thanks for that. I will ask one of the testers if they can help me test those more thoroughly later in the week also. | 07:07 |
| chriadam | ah great! thanks | 07:08 |
| chriadam | on the gpg signature side, I was hoping to merge those last week, but noticed that there are still some discussion items open with pvuorela on the jolla-email PR | 07:08 |
| dcaliste | Yes, thanks for merging. I'll send the mKCal package to Maus who reported the upsync bug, I guess he will be eager to test also. | 07:08 |
| chriadam | true, thanks | 07:09 |
| dcaliste | About the discussions, you mean the naming convention of the new signal in nemo-qml-plugin-email ? | 07:09 |
| chriadam | no, there was a question about adding a dconf key: autoVerifySignature, and then a Loader | 07:10 |
| chriadam | I think pvuorela didn't have a chance yet to respond to that question | 07:10 |
| dcaliste | Ah, yes. This in m opinion, can be added on top later if decided so. | 07:10 |
| dcaliste | But we can also wait for pvuorela to have time to respond of course ;) | 07:11 |
| dcaliste | The question was about to create such a key and make it apparent in UI. | 07:11 |
| chriadam | I pinged him about it earlier today so hopefully by tonight. I'm itching to get it all integrated honestly, it's been too long in queue. | 07:11 |
| dcaliste | This, I think, was becoming more important with a remark from schmittm during the last community meeting. | 07:12 |
| dcaliste | He mentioned that we're using ancient GnuPG stack because of licencing issue. | 07:13 |
| dcaliste | And auto verification of emails may lead to a threat with random bits from the Internet. | 07:13 |
| chriadam | ouch | 07:13 |
| dcaliste | So the auto verification dconf key makes sense to avoid software reading random data everytime there's supposed to be a signature. | 07:14 |
| dcaliste | The user can verify key for selected emails that looks originating from a trusted person. | 07:14 |
| dcaliste | The other solution I see is to package a GnuPG-latest but not distributing it. | 07:15 |
| dcaliste | Like that user would cares can pkcon install email-pgp-plugins + gnupg-latest. | 07:15 |
| chriadam | regarding the former: maybe we should turn off auto-verification by default? | 07:15 |
| chriadam | regarding the latter: that sounds like a good idea, maybe we should ask lbt about that? but hopefully some gplv3 discussions are reaching their conclusion shortly anyway..? | 07:16 |
| dcaliste | Indeed, and let the user turn it on or off we a dconf key, or a UI setting. | 07:16 |
| chriadam | right. first version: dconf key is fine. eventually, definitely need a UI setting, but not necessary for first version IMO | 07:17 |
| chriadam | since some command line stuff (e.g. manually installing appropriate packages) is required anyway | 07:17 |
| chriadam | and importing some keys | 07:17 |
| dcaliste | Ok for the dconf key, will add it later today. Last week, we decided also that I need to implement something like autoVerifySignature: numberOfAttachments == 0 | 07:18 |
| dcaliste | But, after rying to do it, it's not doable in the current implementation. | 07:18 |
| dcaliste | Indeed, for POP, everything is downloaded already. | 07:18 |
| chriadam | oh wow | 07:19 |
| chriadam | that I didn't know | 07:19 |
| dcaliste | And for IMAP, I need to rewrite the download part. | 07:19 |
| chriadam | ouc | 07:19 |
| chriadam | ouch | 07:19 |
| dcaliste | Currently, since, I need the pristine data, I start the download anyway of the full part in QMF directly. | 07:19 |
| chriadam | sure | 07:19 |
| dcaliste | I'm thinking how to improve this and reconstruct pristine data after user downloaded by hand the various parts. | 07:20 |
| dcaliste | But it requires quite a work. | 07:20 |
| chriadam | indeed | 07:20 |
| dcaliste | Because I need to save the pristine headers for each part and then reconstruct all. | 07:20 |
| chriadam | what's the current alternative? either never auto verify, or always auto verify (requiring full download)? eh, that seems ok for now. | 07:21 |
| dcaliste | While now, I'm saving the full part anyway, which is simpler as a first approach. | 07:21 |
| dcaliste | No, in fact, it has no relation to autoverification. | 07:21 |
| chriadam | oh | 07:21 |
| dcaliste | The bits are downloaded anyway currently when the messageserver see that the email is a signed one and save all bits on disk. | 07:21 |
| chriadam | ah, it downloads everything regardless? | 07:21 |
| chriadam | ok | 07:22 |
| dcaliste | Then, depending on verification policy, the qml-plugin verifies or not the data. | 07:22 |
| chriadam | that's suboptimal :-/ does that "when messageserver see the email is a signed one" behaviour only occur if the appropriate packages are installed? or does it happen regardless? | 07:22 |
| dcaliste | The idea for the future is not to download data uniformally, but to download just the pristine headers and reconstruct the pristine part from headers and downloaded data from user actions. | 07:23 |
| chriadam | right | 07:23 |
| dcaliste | The behaviour of the messageserver depends on the installation of plugin indeed. | 07:23 |
| chriadam | great | 07:23 |
| chriadam | in that case, sounds fine to me. if we can improve things in the future, great, but shouldn't block things for now IMO | 07:24 |
| chriadam | hopefully pvuorela agrees | 07:24 |
| dcaliste | The logic is only the plugins can say which parts should be pristine for verification, even if the message server knows without plugin that a message is signed or not. | 07:25 |
| dcaliste | The RFC about MIME and multipart emails just say that the mail is multipart::signed but not how to verify. | 07:25 |
| dcaliste | The plugins implementing PGP or S/MIME add the information which part should have pristine data for verification. | 07:26 |
| dcaliste | The "problem" in the RFC (but it's logical) is that the headers are also required to check the signature, not just raw data of the attached file for instance, which makes the data retrieval and save disk a critical part if bits in the headers are changed or not saved pristine. | 07:27 |
| chriadam | indeed | 07:28 |
| dcaliste | This has never been an issue with POP, since the full email is always downloaded. But IMAP is another story… | 07:28 |
| dcaliste | Headers can be retrieved separately, but was never saved pristine in the old QMF, now we can save then, but to simplify the first implementation, I decided to download the signed part at once, even if this part contains sub-parts or several attachments. | 07:29 |
| dcaliste | It's on my todo list, but I'm waiting for first adoption and first feedback about current implementation and UI flow. | 07:30 |
| chriadam | yep | 07:32 |
| chriadam | no worries, thanks for the explanation | 07:32 |
| dcaliste | Hopefully we'll have git-hosted static pages in sailfishos.org to document all of this ;) | 07:33 |
| chriadam | are you thinking some markdown style wiki or? | 07:33 |
| dcaliste | I'm eager to explain how things works in QMF or higher in the stack, so others can learn from that. | 07:34 |
| chriadam | if you send me some text, I can add it to the sailfishos wiki, but it's currently not git hosted / modifiable by non-internals | 07:34 |
| chriadam | also it's likely to go out of date quickly if we don't remember to keep updating that wiki ;-) | 07:35 |
| dcaliste | Whatever, but something like the old sailfishos.ork wiki where the architectural parts are explained. | 07:35 |
| chriadam | https://bz.jollamobile.com/show_bug.cgi?id=44057 | 07:35 |
| chriadam | uh | 07:35 |
| chriadam | wrong copy paste sorry | 07:35 |
| chriadam | https://sailfishos.org/wiki/Email | 07:35 |
| dcaliste | lbt was speaking of this kind of upgrade for the merge between sailfishos and merproject. So people can participate to the technical documentation and it can be reviewed by sailor. | 07:36 |
| chriadam | that would definitely be good | 07:36 |
| chriadam | haven't heard about that, internally, yet | 07:36 |
| dcaliste | Ah, maybe it was just an idea on IRC at one point ;) | 07:37 |
| dcaliste | I can write some more text for the Email wiki page though and send it to you later. | 07:37 |
| chriadam | or maybe I haven't been paying attention enough to the plans discussed in internal ops calls / meetings ;-) | 07:37 |
| chriadam | but yeah, that'd be great also | 07:37 |
| chriadam | cheers | 07:37 |
| dcaliste | Yes, at work we're also migrating from wiki to git-hosted documentation written in markdown, we find it simpler to interact or review changes. | 07:38 |
| albertux | chriadam: Hello chriadam, I'm draining battery problem with contactsd yet....it's a problem I must travel with BIG power bank.... | 07:40 |
| chriadam | albertux: I recall the conversation, I don't recall the outcome | 07:52 |
| chriadam | albertux: ISTR that you have various XMPP accounts? roster changes can trigger activity, which could cause some of it | 07:53 |
| chriadam | but most likely the cause is bad sync cycles between the privileged and non-privileged databases. | 07:53 |
| chriadam | we should get rid of the non-privileged database altogether, IMO | 07:53 |
| chriadam | but that's something which needs addressing later on, e.g. after daemonising the contacts API access | 07:54 |
| albertux | chriadam: Ok, wil you solve the problem with next release? | 07:54 |
| chriadam | albertux: highly unlikely | 07:55 |
| albertux | chriadam: The terminal is now pretty unusable... | 07:55 |
| chriadam | if you disable your XMPP accounts, does the situation improve? | 07:56 |
| albertux | 100% to 10% battery in about 4 hours.. | 07:56 |
| albertux | no, the situation remain equal | 07:57 |
| chriadam | huh. | 07:57 |
| chriadam | albertux: in that case, must be something messed up with non-privileged <-> privileged contacts database sync, unfortunately. | 07:58 |
| chriadam | let me quickly check something | 07:58 |
| *** Piece_Maker is now known as Acou_Bass | 07:58 | |
| albertux | A friend of mine, skilled on Linux, have tried to cancel the old database.... and automatically lhe sustem created a new one, with same problems.. :) | 07:58 |
| albertux | it is NOT a good news.... :( | 07:59 |
| dcaliste | chriadam: sorry to interrupt, I'll need to attent a lab meeting now. To summarize: I'll add later today the dconf entry for autoSignatureVerification and propose a UI setting based on loader in the existing separated package for signature. I'll send the new mKCal package to Maus for testing. | 08:01 |
| chriadam | dcaliste: thanks very much | 08:01 |
| chriadam | have a great week! hopefully we get the signature PRs merged this week... fingers crossed... | 08:01 |
| chriadam | albertux: can you try: | 08:02 |
| dcaliste | We can also continue the discussion in bitbucket with pvuorela about the up-sync on change in calendar app. See you later and have a nice evening. | 08:02 |
| chriadam | albertux: `devel-su dconf write /org/nemomobile/contacts/export/disabled true` | 08:02 |
| chriadam | err. actually, `devel-su -p dconf write /org/nemomobile/contacts/export/disabled true` | 08:03 |
| chriadam | albertux: and similarly `devel-su -p dconf write /org/nemomobile/contacts/export/import false` | 08:04 |
| chriadam | does that make any difference to contactsd activity? | 08:08 |
| albertux | chriadam: done...now reboot | 08:10 |
| albertux | contactsd raise to 60% cpu in 3min... :( | 08:12 |
| albertux | chriadam: ohps..... now I must go away......I return in the afternoon, are you still here? | 08:13 |
| chriadam | albertux: no, about to head home | 08:14 |
| chriadam | it's late here in .au | 08:14 |
| albertux | :) | 08:14 |
| chriadam | ping me tomorrow, I will investigate. very curious | 08:14 |
| albertux | bye, see you! | 08:14 |
| chriadam | good night! | 08:14 |
| *** frinring_ is now known as frinring | 08:42 | |
| attah_mobile | Is Harbour QA on vacation? | 12:53 |
| mal | why do you think that? | 12:57 |
| attah_mobile | Submitted 2 days ago and not a word. Has always been taken care of by lunch the following work day... | 13:00 |
| attah_mobile | (which is excellent) | 13:02 |
| *** kaol_ is now known as kaol | 14:48 | |
| *** frinring_ is now known as frinring | 16:56 | |
| *** outside is now known as grumplestiltzkin | 18:27 | |
| Almindor | what would be the appropriate notification category to use for an incoming audio/video call (think skype)? | 20:27 |
| Almindor | I can't see any call related categories defined in /usr/share/lipstick except for missed call for some reason | 20:28 |
| Almindor | anyone knows how to access the proximity sensor (the "phone is on ear" detection one)? | 21:51 |
| mal | via Qt sensors (or directly via sensorfwd) | 21:59 |
| mal | Almindor: why do you ask? | 21:59 |
| Almindor | I need to "enable" the "shut down screen when on ear" mode from my app | 22:03 |
| Almindor | unless it's done in some sort of generic way with mce? | 22:03 |
| mal | yes, mce handles that usually | 22:23 |
| Almindor | mal: how do you enable it tho? I can't find anything related to proximity mode in https://git.merproject.org/mer-core/mce-dev/blob/master/include/mce/dbus-names.h | 22:56 |
| r0kk3rz | im not sure you need to enable it at all | 22:59 |
| r0kk3rz | generally prox blocks touch | 22:59 |
| r0kk3rz | as for the notifications, im not sure there is an appropriate system call for that type of thing | 23:00 |
| r0kk3rz | it would be nice to be able to hook into the call ui | 23:00 |
| mal | Almindor: I think that feature might not be available to apps, but I haven't looked into that | 23:02 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!