| *** frinring_ is now known as frinring | 02:28 | |
| *** zbenjamin is now known as Guest88126 | 02:44 | |
| *** zbenjamin_ is now known as zbenjamin | 02:44 | |
| *** nyov is now known as Guest15998 | 04:26 | |
| dcaliste | Good evening chriadam, how are you ? Thanks for the various merges ! | 07:59 |
|---|---|---|
| chriadam | hi dcaliste | 08:01 |
| chriadam | I'm well, thank you | 08:01 |
| chriadam | how are you? | 08:01 |
| chriadam | no worries, was meant to get to them last week, but didn't get around to it until today | 08:02 |
| chriadam | I also poked Martin about the event reminder time selection thing, and he has uploaded a design prototype to your PR | 08:02 |
| chriadam | and flypig said he'd look into the outstanding nemo-qml-plugin-calendar PR | 08:03 |
| flypig | Yes, I'll try to look at it today. | 08:03 |
| chriadam | thanks! | 08:03 |
| dcaliste | Thank you both. I've seen the message from Martin. Lease transmit my thanks to him also. | 08:07 |
| chriadam | cheers, done | 08:08 |
| dcaliste | Do you have time now to discuss the account enable binding with buteo profile bindings ? | 08:09 |
| chriadam | yes | 08:10 |
| chriadam | I took a quick look | 08:10 |
| chriadam | so, is it the case that: | 08:10 |
| chriadam | there was some code in buteo to "track account enablement changes, and ensure that the sync profiles associated with those accounts were enabled/disabled appropriately" | 08:11 |
| chriadam | but we had disabled it due to bugs | 08:11 |
| chriadam | and then, we simply check the account enabled status in the various sync plugins instead | 08:11 |
| chriadam | OR -> do we manually set the profile to disabled, when the account is set to disabled, in j-s-a (I assume not, but that was another possibility, I guess) | 08:11 |
| dcaliste | As far as I understand it, it's the first case. Profile enable status is not in sync with the account one (machinery disabled in buteo) and every plugins still fire and quick return when the account is disabled. | 08:13 |
| dcaliste | This is somehow inellegant but works well for all plugins... except the webcal one that is not using account machinery in the plugin itself. | 08:14 |
| chriadam | yup, that's also what I thought. would be nice to avoid that "msyncd creates plugin process, plugin process checks account status and immediately exits" silliness, definitely. | 08:14 |
| chriadam | I still don't fully understand how the webcal plugin works, I think. | 08:14 |
| dcaliste | Yes, instead of adding account checking in the plugin I decided to give a look to the disabled part in Buteo, in case. | 08:15 |
| dcaliste | About the webcal plugin, it's basically a CalDAV in slow sync all the time. | 08:15 |
| chriadam | do we create an accounts&sso account, associated with the webcal endpoint, at all? or is it solely a sync profile which we trigger somehow? | 08:17 |
| dcaliste | Sorry, I got side-tracked by colleagues... We're creating an account for it, because it's simpler in the UI to follow existing workflow, but the account is not used in the buteo plugin. | 08:22 |
| dcaliste | The webcal resources are often if not all time free of access. | 08:22 |
| chriadam | right | 08:23 |
| chriadam | so we create the account so that it shows up in the accounts UI, and now so that we can enable/disable the profile just by enable/disable the account? | 08:23 |
| dcaliste | Could I be absent 5-10 minutes more ? I need to fix something here :/ | 08:23 |
| chriadam | no rush | 08:24 |
| chriadam | yes | 08:24 |
| chriadam | of course | 08:24 |
| dcaliste | Ok, sorry. I'm free now. So the problem that araised, is that enabling / disabling the webcal account in UI has no effect on the sync since only the profile is used. | 08:32 |
| chriadam | right | 08:32 |
| chriadam | on the buteo-syncfw side: can you describe at a high level what your change does? there are some things which I don't remember about at all | 08:33 |
| chriadam | e.g. there seems to be an assumption in that code that the sync profile name should match the account service name, but that's not true for us, I think. | 08:34 |
| dcaliste | Exact, so I rewrote that. | 08:34 |
| chriadam | i.e. when creating the sync profiles for the account | 08:34 |
| dcaliste | I'm following the sailfish-component-account convention now, looking for a template name. | 08:35 |
| dcaliste | So there was this problem to associate account service with profile in the existing buteo code, but there was also some strange things like modifying some account settings in particular cases. | 08:36 |
| dcaliste | I've totally removed that. | 08:36 |
| dcaliste | The code is much simpler now. | 08:36 |
| chriadam | again, a lot of this might be historical, e.g. we previously had some sync profiles which were associated with multiple services, i.e. would only activate if both services were enabled, for example | 08:36 |
| dcaliste | It is triggered on account enable signal (which may trigger on no changes we know about that now) and it is updating only the profile enable status, based on current account / service enable status. | 08:37 |
| chriadam | and some where a single account service was used to activate multiple sync plugins (e.g. microblog service for facebook would enable both posts sync and also notifications sync, IIRC) | 08:37 |
| dcaliste | I think, I'm keeping this. We have the same for Nextcloud. | 08:38 |
| dcaliste | I've tested for CalDAV, webcal and Nextcloud that changing account and/or service in UI is triggerring the right profile. | 08:38 |
| dcaliste | The logic finally is quite simple : | 08:39 |
| dcaliste | - if account or service is disable, find the associated profile based on template naming and disable it, | 08:39 |
| dcaliste | - if the service is enabled but the global is still disable, find the associated profile and disable it, | 08:40 |
| dcaliste | - if the account is enabled, but not the specific service, same as above, | 08:40 |
| dcaliste | - if both are enabled, enable the associated profile. | 08:40 |
| dcaliste | Everything stands on the fact that we can rely on account-service/profile matching. | 08:41 |
| chriadam | what can cause disable/enable of account? just wondering if there are cases (like backup/restore) which might affect things | 08:42 |
| chriadam | not a question for you, more just a thinking point for me | 08:43 |
| dcaliste | Beside direct action of user you mean ? Because long press on the account allow to disable it in settings. Also, there is a combo on every account page to enable / disable the account. | 08:44 |
| dcaliste | The account can be disabled by mdm also I think from the code I've seen. | 08:44 |
| chriadam | yes, besides direct action by user | 08:46 |
| chriadam | worrying about possible case of e.g. user manually disables something, then performs action like backup/restore which might "automatically" disable->do_whatever->enable account. at the end of the cycle, the account is in different state to what it should be. | 08:47 |
| chriadam | but, anyway, it's unrelated to this case, per-se | 08:47 |
| chriadam | just thinking out loud | 08:48 |
| chriadam | I mean, the semantics you described sounds very sensible. | 08:49 |
| dcaliste | Well, about account changing state, this MR has no effect on this. In contrary to the code it is changing, it's not changing anything to the accounts it is listening to. | 08:49 |
| chriadam | yes, that's true | 08:50 |
| dcaliste | It only tries to match the profile enable status with the one of the account. | 08:50 |
| chriadam | I guess I just meant: it's another side effect which might be triggered if that bug pre-exists elsewhere | 08:50 |
| dcaliste | Your concern in Gitlab about when the slot is triggered is valid though. In my testing it was working to disable or reenable the global account and have the profiles that reflect this. But I will check again for sure. | 08:51 |
| chriadam | out of interest: were you able to determine precisely why we disabled this behaviour originally? was there any commit message or something which described precisely what bug was hit originally, which made me just disable it all? | 08:51 |
| dcaliste | I looked at the blame, and you did it ! | 08:52 |
| chriadam | I remember disabling it | 08:52 |
| chriadam | I just don't remember why ;-) | 08:52 |
| dcaliste | The commit message mentioned bug and race conditions but did enter into details. | 08:53 |
| chriadam | ah I will check the bug number and see if I can find the info. sec | 08:53 |
| dcaliste | The fact that the earlier code was relying partly on the enabled value of the signal, and not the actual value by poking the account itself may be responsible. | 08:53 |
| dcaliste | The fact also that in some case, this code generate a change in account setting themselves is suspicious to me. | 08:54 |
| dcaliste | I've completely removed this. I didn't see any use for it. | 08:54 |
| chriadam | I will send you an email | 08:55 |
| chriadam | with the info | 08:55 |
| dcaliste | Great thank you. | 08:55 |
| dcaliste | So I can check I'm not reactivating some old demons :) | 08:56 |
| dcaliste | The main concern I may have with this modification is if something is wrong somewhere, a profile may stay disabled while the account/service is active and the user won't notice anything, except that it's not syncing... | 08:57 |
| dcaliste | This is JB#33183 from the commit message of 76e33195a86e1b8c050db11d98b164922f6b58df | 09:01 |
| dcaliste | I would like to mentioned also that I didn't completely revert your changes from this commit. | 09:01 |
| dcaliste | Indeed, you also disabled sync schedule syncing between account and profile, which you're right made no sense in current usage. | 09:02 |
| dcaliste | This I'm keeping it disabled ! | 09:02 |
| dcaliste | I just reenabled the enable status following. | 09:02 |
| chriadam | dcaliste: for some reason I couldn't email it, got some error. so I posted the info as a comment on the j-s-a PR#127 | 09:05 |
| chriadam | the short answer is: I think that the signal handling was triggering msyncd to try to load all sync profiles one-by-one from disk, and this was taking a long time in IO-congestion cases like restore | 09:05 |
| chriadam | instead of fixing it properly (i.e. changing msyncd to have an in-memory cache of available profiles) I just ... disabled the signalling. | 09:06 |
| dcaliste | Yes, thank you. I see the use case indeed. Before doing anything with this MR, I'll check how the new code can handle this use case and see if I need to change something. | 09:07 |
| dcaliste | Thanks for the information. | 09:07 |
| chriadam | edited that ocmment now for more readability too | 09:08 |
| chriadam | I will also do some tests into this. it may no longer be a problem, in any case, as we changed a bunch of things in the meantime | 09:09 |
| chriadam | e.g. there was a change to disable msyncd altogether during backup/restore | 09:09 |
| chriadam | let me find that one... | 09:09 |
| chriadam | [jolla-vault] Prevent synchronization during restore. Contributes to JB#38210 | 09:10 |
| chriadam | yes, so that bug number 38210 is greater than 33183 | 09:10 |
| chriadam | so I suspect that this isn't an issue any more | 09:10 |
| chriadam | as none of that stuff should get triggered during a backup/restore at all, now., | 09:10 |
| chriadam | well, will give it some thought and testing :-) | 09:12 |
| chriadam | I think it should be fine. | 09:12 |
| chriadam | given the fast-approaching christmas vacations, it's unlikely I'll merge these two this year | 09:13 |
| chriadam | I hope that's ok? | 09:13 |
| dcaliste | No problem, it's not important ! | 09:15 |
| chriadam | thanks very much | 09:16 |
| chriadam | did you have anything else to discuss today? was there any PRs which slipped my memory? | 09:16 |
| dcaliste | This one maybe : jolla-calendar #278 | 09:17 |
| chriadam | poked joona and pekka about that one earlier | 09:17 |
| chriadam | it's a one liner which should just be merged imo | 09:17 |
| chriadam | but ... will let them approve that one first | 09:17 |
| dcaliste | Hopefully yes ;) | 09:17 |
| dcaliste | One last thing, if you don't mind : | 09:17 |
| chriadam | sure :-) | 09:18 |
| dcaliste | https://github.com/sailfishos/sailjail-permissions/issues/15 | 09:19 |
| chriadam | ah. interesting... | 09:19 |
| dcaliste | Currently the signing process for an email is broken, I guess because of missing permissions in sand boxing. | 09:19 |
| dcaliste | I'm eager to investigate it, but I would appreciate some hints if time allows it. | 09:20 |
| dcaliste | I think, I should do something like account is doing, or msyncd. But at first sight, the permission syntax is not that clear to me. Particularly the part dealing with DBus. | 09:21 |
| chriadam | unfortunately I know very little about the sandboxing stuff, currently - I need to get myself up to speed.. | 09:21 |
| dcaliste | Not that DBus itself has a crystal clear syntax neither... | 09:21 |
| chriadam | spiiroin or rainemak would be able to help I think | 09:21 |
| chriadam | I have pinged Raine internally, hopefully he or Tomin get a chance to add some information to the issue | 09:23 |
| dcaliste | Kind of hints like, how to run the thing in CLI with verbose output so I know which access is blocked by firejail. | 09:23 |
| dcaliste | Because I'm afraid that enabling things blindly in a permission file would take a lot of time. | 09:23 |
| dcaliste | Thanks chriadam for the message in the issue. | 09:25 |
| chriadam | let me try to find a link, sec | 09:26 |
| chriadam | hrm, nope, couldn't find what I was looking for... I think in any case, waiting for one of the MW devs to answer would be best, otherwise I might tell you something wrong haha | 09:29 |
| chriadam | https://github.com/sailfishos/sailjail-permissions/blob/master/permissions/voicecall-ui.profile has one example of permission to talk to a dbus endpoint -- but that one is session bus | 09:30 |
| chriadam | sorry I cannot help further :-( | 09:32 |
| dcaliste | Yes, I don't know because we're not speaking directly through DBus, but are using a library that is speaking DBus internally. Maybe it's the same ? | 09:32 |
| dcaliste | Anyway, I'll wait for more information. Particularly about getting verbose info from CLI would be usefull to investigate. | 09:33 |
| dcaliste | Maybe I can find directly something on the Internet about firejail itself. | 09:33 |
| chriadam | perhaps so | 09:33 |
| dcaliste | I'll keep you updated on progress ! | 09:34 |
| chriadam | thanks :-) I am interested to learn how it works, also ;-) | 09:34 |
| chriadam | and thank you again for your time and effort as always! | 09:34 |
| chriadam | it is much appreciated | 09:34 |
| chriadam | are you going on vacation next week, or will you be available also next Tuesday? | 09:34 |
| dcaliste | I guess it's now running late for you, so I wish you a good week. | 09:34 |
| dcaliste | I may be available next Tuesday if you're also. In case I cannot I'll email you before Monday evening. | 09:35 |
| dcaliste | If that's fine enough for you ? | 09:35 |
| chriadam | sounds good - I should be here, but no problem if you're busy etc :-) | 09:35 |
| chriadam | oh, also: | 09:35 |
| chriadam | do you want some Jolla t-shirt or scarf or anything for christmas? | 09:35 |
| chriadam | I think someone told me that we have some stuff we should be able to send you if you would like | 09:36 |
| dcaliste | Thanks that fine ! Why not a scraf ? That could be usefull, winter has established itself here ;) | 09:36 |
| chriadam | excellent! I will give your email address to the appropriate person internally and ask them to get in contact with you, if that's ok? | 09:37 |
| dcaliste | Sure, thank you ! | 09:37 |
| chriadam | :-) Ok, have a great week! | 09:37 |
| chriadam | gnight | 09:37 |
| *** albertux1 is now known as albertux | 10:03 | |
| *** albertux1 is now known as albertux | 17:30 | |
| *** albertux1 is now known as albertux | 17:37 | |
| piggz | rinigus: ping | 19:50 |
| rinigus | pong | 20:06 |
| rinigus | piggz: ^ | 20:06 |
| piggz | rinigus: components question ... | 20:09 |
| rinigus | ... | 20:10 |
| piggz | in the combobox .. how do i use it with a c++ model that has 2 roles ? | 20:10 |
| piggz | or, do i have to limit it to 1 role ? | 20:10 |
| piggz | qqc2 allows a text and value role, but thats maybe not portable | 20:10 |
| rinigus | checking | 20:12 |
| rinigus | piggz: I didn't need it => it was not implemented. as for portability, no idea. | 20:13 |
| piggz | ok, i will just make it work with the 1 role for now | 20:14 |
| rinigus | piggz: you are welcome to extend components and make them better :) | 20:16 |
| piggz | rinigus: looks like im expecting some PRs on amazfish, for integration with postmarketOS | 21:40 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!