Tuesday, 2020-10-27

*** zbenjamin is now known as Guest2820002:12
*** zbenjamin_ is now known as zbenjamin02:12
*** nyov is now known as Guest8049504:10
dcalisteHello chriadam, how are you ?07:59
chriadamhi dcaliste08:03
chriadamI'm well thanks08:03
chriadamhow are you?08:03
dcalisteFine, thank you. I've seen your MRs in gerrit for QtPim. I've started to give a look but didn't finish.08:04
dcalisteMainly, we've faced the same problems for QMF.08:04
chriadamoh, thank you.  I am hoping to get those all integrated this week, as pvuorela kindly +2'd those qtpim ones already08:04
dcalisteI've mainly looked at how it's done, and it should be the same in QMF MRs and your QtPIM ones.08:05
chriadamhopefully - let's see if it passes CI ;-)08:05
dcalisteIndeed !08:05
chriadamsorry, I dc'd08:06
chriadamregarding the caldav PR: I'm not sure precisely how Bree encountered the issues she hit.  interestingly, one of those at least reproduces with master branch, so not a regression caused by the PR itself, apparently08:07
chriadamI haven't had a chance to investigate precisely what is happening, or repro myself08:07
dcalisteI'm curious about how to reproduce.08:07
dcalisteI don't have the problem with my OpenXChange account and I'm modifying exceptions regularly: physiotherapist time changes ;)08:08
dcalisteI'm doing all modifications and creations on device, the server being mainly a kind of backup in my use cases.08:08
chriadamI didn't see the issue with my brief testing either, but bree's testing was more comprehensive than mine, so hopefully she will be able to give precise repro instructions :-)08:09
dcalisteI'll try to see if it's the same when exceptions are initiated on server.08:09
dcalisteIndeed, let's also wait for reproduction instructions.08:10
dcalisteAbout CalDAV, you may have seen my MR from yesterday about a forum issue of calendar not syncing anymore from a Radicale server.08:10
dcalisteIt's a problem in the calendar discovery code.08:10
chriadamoh, I didn't see that one yet08:11
chriadampath construction, or?08:11
dcalisteRequest class is ignoring 403 errors and returning success in that case. Which confuses the later logic in CalDavClient because well this is an error but it takes the success code path.08:11
dcalisteI hesitated many time with flypig yesterday about the best way to solve this. At first, I wanted to remove the Request "hack" of treating 403 error as a success, but it's very intrusive to keep the backward compatibility.08:13
dcalisteFinally, I ended up with a modification in CalDavClient to also take the error code path when the response is 403. It's a bit hacky and I put a comment there to mentioned that it comes from the Request treatment of 403 errors.08:14
dcalisteI've packaged the MR and the user seems to be happy with it.08:14
chriadamsounds like a good pragmatic solution08:14
dcalisteSee https://forum.sailfishos.org/t/after-upgrade-to-3-4-0-24-caldav-sync-stopped-working/3118/1108:15
dcalisteAnd https://git.sailfishos.org/mer-core/buteo-sync-plugin-caldav/merge_requests/7308:15
chriadamthanks, I will check tomorrow08:15
dcalisteThank you.08:16
chriadamthank you very much for investigating and fixing08:16
chriadamalso, thanks for the email you sent the other week with the information about the kcalcore upgrade status08:16
dcalisteWell, the user was very nice and provided before asking all necessary information to quickly understand the root issue.08:16
chriadamwe discussed it briefly in sprint planning, but no concrete plan for who will be able to work on that one yet unfortunately08:17
chriadamwe have some loose ends we need to tie up on customer projects, then we'll have a clearer idea of availability within the team internally08:17
dcalisteAbout KCalCore upgrade, don't hesitate to ask question if something requires more information. And thank you for considering this internally.08:18
chriadamoh, I forgot to ask: how was your vacation last week?  hopefully nice and relaxing08:19
dcalisteIt was great, went sailing on the Mediterranean coast with friends for a week. The weather was great for autumn and we even succeeded to swim.08:20
chriadamsounds great08:21
dcalisteIt changed mind from the gloomy corona ambiance…08:21
chriadamyes, so important to keep good spirits in these somewhat depressing times08:21
dcalisteYou may end up in confinment soon here again :/08:21
dcalisteSorry, we…08:21
dcalisteNot you !08:21
chriadamhopefully the winter weather in the northern hemisphere doesn't drive another wave of infections :-(08:22
chriadambut anyway, I'm glad that you had a great vacation08:22
dcalisteAbout KCalCore transition, having https://git.sailfishos.org/mer-core/kcalcore/merge_requests/21 accepted would allow to modify mKCal ExtendedCalendar to inherit from MemoryCalendar.08:23
chriadamwere there any other PRs to discuss - I unfortunately haven't progressed any outstanding things on my end.  not sure if the jolla-calendar things have progressed?  flypig?08:23
dcalisteDoing this would save a lot of KDateTime to QDateTime transition there.08:23
chriadamoh, I remember that kcalcore MR.  yes, I will merge that one asap.08:23
dcalisteBecause most of them would be in KCalendarCore already.08:23
dcalisteAnd if flypig is here, I would like to discuss the problem of calendar visibility that come back when editing setting page or event at each sync cycle for Google account.08:24
dcalisteDid you remember, the issue we began to discuss last time about the Contactd plugin that change visibility on account enable changes ?08:25
chriadamhe was online a little while ago at least, hopefully he's around08:25
flypigI'm around...08:26
flypigI'm just checking the status of https://bitbucket.org/jolla/ui-jolla-calendar/pull-requests/266/08:26
dcalisteI've investigated the problem of libaccount-glib emitting enableChanged signal too often.08:26
dcalisteHello flypig !08:26
flypigHi :) I'm glad you had a good break.08:27
flypigWhat was your conclusion (about libaccount-glib)?08:27
dcalisteWell, it is not emitting this signal too often in fact. And we cannot by design add a signal on "real" change.08:28
flypigThat's too bad.08:29
flypigBut that suggests some other issue then?08:29
dcalisteIt is due to a server/client design to enable concurrency.08:29
dcalisteWhen an account manager is calling setEnable(), the signal will be emitted even if there is no change.08:30
flypigThat was the underlying issue, as I understood it.08:30
dcalisteBecause, this manager cannot know if the database actually reflect the value is possess because some concurrent process may have changed the value in between and the change signal may not be propagated yet.08:31
dcalisteIn fqctm it4s not completely the issue at hand, let me explain why:08:31
flypigAh, I see.08:31
dcalisteIf you don't call setEnable(), the enableChanged signal is *not* emitted.08:32
dcalisteSo if your code don't care about the actual status of the account in storage and just want to store a setting like the sync token for this account, then the signal is not emitted by libaccount-glib.08:33
dcalisteBut in UI, the signal is emitted anyway, because, the sailfish-component-accounts is calling setEnable() unconditionnally and thus the signal is emitted every time the UI is calling sync().08:34
dcalisteThere is something we need to decide here about sailfish-component-accounts:08:34
dcaliste- current situation is that when syn() is called in QML, the account status (enabled or disabled) is enforced, whatever the change that is done. It is safe because we're sure that the status is the one reflected in UI. But it emits the enableChanged signal at each sync() call.08:36
dcaliste- possible corrected situation is to call setEnable() only when the UI actually flip it. Then, the signal is emitted properly, but it creates a race condition where the user may see an enabled account but actually a background process diasble it before it confirm the settig dialog and at the end the account is not enabled when the setting dialog is confirmed.08:37
dcalisteWhat do you think flypig and chriadam ?08:37
chriadamflypig was working on something to ensure that only a "delta" of changes is applied, rather than every setting, iirc08:39
chriadamwhich might mean the second (only call setEnabled() when the ui flips it) will happen08:39
chriadambut not sure of the status of that work, currently08:39
chriadamor am I remembering wrongly, flypig ?08:40
flypigYes, that's been merged in already.08:40
chriadamoh, great08:40
dcalisteYes, but the issue is deeper in sailfish-component-accounts, I think, look at line src/lib/account.cpp#62308:40
flypigBut I'm not 100% sure if it affects enabled/disabled status, because they're a bit special.08:40
dcalisteThis setEnabled() is called unconditionnally there.08:40
dcalisteAnd this is triggerring the enableChanged() signal.08:41
dcalisteI would suggest to set a flag in Account::setEnabled() and call the setEnagled() on the underlying account only when the flag is on.08:42
dcalisteI would like to propose a MR for this that we can discuss, but I only have read access on this repo !08:43
chriadampvuorela any chance you could give write access ^08:43
pvuorelasuppose that's for the pull request branches, sure, i'll check.08:45
dcalisteThank you pvuorela08:46
flypigCorrect me if I'm wrong, but won't there be a danger that any setEnabled() used somewhere could trigger the same problem. Just for the sake of discussion, I'm wondering if something like an AgAccountWatch could be used instead.08:49
flypigI have a feeling these only apply to properties rather than account/service enabled states though.08:50
flypigFor ref: https://gitlab.com/accounts-sso/libaccounts-qt/-/blob/master/Accounts/account.h#L7008:51
dcalisteIndeed, any call to setEnabled() will trigger the signal and thus the notebook visibility. That's quite a fragile situation, I agree. What is AgAccountWatch ?08:51
flypigAgAccountWatch sends a glib notify whenever a property changes in the database.08:52
flypigHere's the underlying libaccounts-glib code: https://git.sailfishos.org/mirror/libaccounts-glib/blob/master/libaccounts-glib/ag-account.h#L17008:54
dcalisteOk, looking at it indeed, it may work, after all enable status is saved as a setting in fact…08:55
flypigIt may suffer from the same issue as the signal, but might be worth checking.08:56
gmchi folks, I posted on the forum last week, i'm trying to develop a nextcloud tasks app, and was looking at various ways to go about it.. one was using https://git.sailfishos.org/mer-core/nemo-qml-plugin-calendar/, but that does not seem to support VTODO's yet? Also can't really find an example of how to use that, although i guess i can figure it out with a bit of puzzling08:56
gmcthe other way (that i'm pursuing now) is to do the interaction with nextcloud's caldav endpoint completely in the app itself (which also is not ideal, since I found out the XMLHttpRequest in qml doesn't support the REPORT http verb)08:57
gmcso i might want to use QtNetwork, but that is then again another api forbidden by the harbour08:58
chriadamQNetworkAccessManager is forbidden by harbour rules?  really?08:58
gmc(not that I mind too much, i'm alreaady out of harbour anyway due to using sailfishsecrets to securely store credentials)08:58
gmcchriadam: https://github.com/sailfishos/sdk-harbour-rpmvalidator/blob/harbour-qa/allowed_requires.conf does not have qtnework in there08:59
chriadampvuorela: that can't be intentional, surely?08:59
dcalisteflypig, ok, I'm going to give a deeper look at watches, but as you said, I'm afraid it will suffer from the same issue, at first sight. Because the watch code is actually called at the same place the signal enableChanged is called and not by a diff at the database level.09:00
chriadamgmc: in general, my advice would be: implement the requests manually in C++, expose things to QML selectively, don't depend on nemo-qml-plugin-calendar as it's likely to change in future etc I guess09:01
gmcchriadam: anyway, nemo-qml-plugin-calendar is also not in the allowed list for harbour, so I'm slowly coming around to the fact that publishing in harbour is only for the most trivial of trivial apps09:01
chriadamgmc: the buteo-sync-plugin-caldav and buteo-sync-plugin-carddav plugins are useful references if you need example code09:01
pvuorelaqtnetwork https://github.com/sailfishos/sdk-harbour-rpmvalidator/blob/harbour-qa/allowed_libraries.conf#L809:02
dcalisteIf we want to actually emit a "real" change signal, it would mean to add a SQL read statement before actually doing the write one and then propagate the signal through DBus to the manager. But it's very invasive and I'm doubtfull that upstream will like it.09:02
dcalisteqmc: use DBus interface to nemo-qml-plugin-calendar to list or modify events.09:02
chriadampvuorela: you're right, it is there09:03
chriadamgmc: yup, just use QNetworkAccessManager, expose stuff manually to your QML code.09:03
flypigdcaliste, yes, I see what you mean. If you don't mind looking into it at any rate. And otherwise, it sounds like there's the higher-level solution in sailfish-components-accounts.09:03
gmcpvuorela: ok, now i'm confused.. it's a supported library, but i'm not allowed to require it?09:03
dcalisteqmc, as I said, also on forum, buteo-sync-plugin-caldav could also sync TODOs by modifying it not to restrict to event listing in the server request.09:04
dcalisteflypig, yes, that's the plan. I'll check for watchers, and then if not successfull, will submit a MR to saifish-componet-accounts and we can discuss the pros and cons there.09:04
flypigPerfect. Thank you.09:05
flypigApologies in advance if it turns out to be a wild goose chase.09:05
dcalisteqmc, for the buteo plugin for CalDAV, the best in my opinion is to create a setting that enable TODOs syncing. Like that adventurous ones can flip the setting on and get TODOs syncing and all the rest are free from bugs related to TODOs.09:06
dcalisteflypig, : no problem.09:06
dcalistechriadam ^ do you think it's a possible approach to enable TODOs syncing ? I can prepare an MR for this.09:07
gmcdcaliste: ok, still getting my bearings with all this.. the buteo plugin is what is used also for the system calendar and things? i've only looked at the app side of things so far, not the os side of things09:07
chriadamit's something we have discussed in the past.  for actually syncing the data, I see no problem enabling.  but for supporting them properly, that requires a lot of thought and design work in UI side, in Jolla Calendar app / notifications / events view etc I guess09:08
chriadamgmc: yes, the buteo plugins sync the data to the databases, which are then exposed in e.g. the jolla-calendar app09:08
dcalisteYes, Buteo is the syncing framework. It is calling this plugin regularly.09:08
gmcchriadam: for now, i'm creating an app specifically to manage todo's, just like I have on android.. it's completely disjoint from the calendar, which is imho fine09:09
dcalistechriadam, that's the point I think, just enable the sync in background and let gmc work on a UI for it.09:09
dcalisteThe problem with enabling the sync for all is that is may create issues with code paths that are not tested (related to TODOs saving in mKCal and so on).09:09
chriadamdcaliste: well, if he's planning on making a harbour app, it won't be privileged / able to access the system database unfortunately.  he is better off just syncing to app-specific sqlite db or whatever, IMO09:10
dcalisteThat's why I'm suggesting to remove the event listing restriction from the plugin only with a setting.09:10
pvuorelagmc: i'm not sure is the content separation between those two files optimal now, but think they both get applied on the check. though for c/c++ you don't need explicit requires as rpm will automatically add the library dependencies.09:10
gmcpvuorela: ok thanks, that's good to know09:11
dcalistechriadam: but Buteo is priviledge, so regular syncing may happen. Then he can display todos and modify them with with DBus calls.09:11
dcalisteExcept if the DBus interface is restricted to priviledge rights also…09:12
gmcdcaliste: that's what i'm wondering.. i did some exploring, and it only showed me read access09:12
gmcbut I may have to dig deeper09:12
chriadamah, I see what you mean... going forward, I think the dbus APIs might be tightened up also, not 100% sure.  abranson might know more than I09:12
gmcchriadam: so right now i'm indeed writing code to interact with nextcloud directly from the app, but i'd rather see it use the already existing synchronisation with nextcloud that's happening in the os.. but i guess that also requires a more mature app-permission model that's not there yet09:13
chriadamfor now, I'd suggest doing it manually in C++ and storing to app-specific db, and exposing data to QML via your own type registrations / models, personally... my mantra is "reduce external dependencies" and in gmc's case, that means reducing which APIs and system components he depends on.09:14
chriadamI keep dcing09:15
chriadamI definitely suggest looking at the caldav plugin and seeing what would be needed to support TODO syncing in there.  I know dcaliste has already done most of the work09:15
chriadambut the codepaths need thorough testing09:15
abransonyeah it's worth keeping an eye on the repos, things are happening sooner rather than later09:16
chriadamthen, yes, as you say, a better app permissions model is needed.  that's a work in progress... no promises on ETA or details.09:16
gmcyeah, so i think for now indeed the approach i have now (do it myself) is the fastest way to get this app up and running..09:16
dcalistechriadam, in the Buteo plugin, every thing is ready at the moment. Just that the request sent to server is asking for filtering events only. We may add a OR filter saying we would like the todos also.09:16
gmchappy to do any testing on todo-enabled os infra though, to get things moving forward to a more ideal picture09:17
dcalisteIt's a one-line modification, but it will trigger code path that are not tested in mKCal.09:17
gmci'll look into installing the platform sdk sometime soon, i guess that's what's needed to work on this stuff09:17
chriadamgmc: yep.  that would be greatly appreciated.  dcaliste knows more about the caldav/kcalcore/mkcal side than anyone else currently, and flypig and I will be more than happy to help if you have any questions also09:18
flypigFor sure.09:19
chriadamdcaliste: maybe we should just flip the switch (and expose via a setting in the accounts UI, as you suggest)09:19
gmci'll probably need some, i'm still in the 'it's all so overwhelming' phase of entering a new project :)09:19
chriadamhaha no doubt, and no worries09:20
gmci'll get there :)09:20
chriadamI am not on IRC much these days, but will be here every tuesday, at about now minus 1.5 hours09:20
chriadamaside from that, feel free to send me an email whenever09:20
chriadamdcaliste: did you have anything else to discuss today?09:21
chriadamif not, just to sum up:09:21
gmci must say, it's been a while since i was really active on irc as well :)09:21
chriadam1) caldav PR - get the repro instructions from bree09:21
chriadam2) mkcal PR - the memory calendar PR - review/test/merge this one09:21
chriadam3) there was a kcalcore PR with unit tests now added, right?  I need to reivew/test/merge that one also?09:22
chriadamand then 4) for flypig, is there something on our side needed for the jolla-calendar PR?09:22
chriadamI will do 1+2+3 tomorrow and thursday09:23
flypigYes, I've asked pvuorela to take another look at the strings. That's the only outstanding issue as far as I'm aware.09:23
pvuoreladcaliste: pr access perhaps better now.09:23
chriadamok great09:23
flypigchriadam, dcaliste, can I also request your thoughts on this please: https://git.sailfishos.org/mer-core/buteo-sync-plugins-social/merge_requests/7309:23
dcaliste2) -> this MR is not published yet. To be added from my side after the KCalCore is accepted.09:23
chriadamI will check that one also tomorrow, flypig09:23
flypigMany thanks.09:23
dcaliste3) tests have been added, indeed.09:24
chriadamsounds good, thanks very much as always for your time and effort.09:25
chriadamanything else to discuss?09:26
dcalistepvuorela, yes it works to push there now. Thanks09:26
dcalistegmc and chriadam, I'll do some tests with my OpenXchange account to see if I can down sync some todos. There are some peculiarities with the calendar layout on the server. The tasks are not in the same notebooks and so on.09:26
chriadamah, todo-specific collection?09:27
dcalisteThat's fine chriadam. Thank you for all the exchanges today. Thank you also flypig and pvuorela.09:27
gmcdcaliste: cool, thanks09:27
flypigThanks from me too :)09:27
chriadamthanks again!  have a great week!09:27
* chriadam -> away09:28
dcalisteYes, there is a todo specific notebook by default. But I guess that's server specific.09:28
*** frinring_ is now known as frinring09:28
pvuorelaone potentially problematic detail with VTODO can be the coupling with time. might be what you wnat, but also often todo lists can be understood as just list of things to do.09:31
gmcpvuorela: indeed, personally i never use times in my VTODO's.. If there is something that must happen on a certain day, it's a VEVENT for me.. but other people may use these things differently of course09:34
*** Sail0r_ is now known as Sail0r09:35
dcalisteflypig, I've started to look at your MR in Google sync, but have not finished yet !09:36
flypigOkay, great, I v.much appreciate it. I think I mentioned on the MR, but I think the changes are much clearer if each commit is taken separately.09:37
flypigBut the big change is switching to use device-time rather than server-time for the change delta.09:39
dcalistelbt or pvuorela, may you look at https://git.sailfishos.org/groups/mer-core/-/activity ? It seems that the hook on Maintainer changes is triggered in a loop since yesterday…09:56
lbtdcaliste: ty - I'm looking at it09:57
dcalisteThanks lbt09:58
lbtit was all Thaodan's fault :D :D :D10:04
dcalisteUhuh, thanks for the correction lbt.10:09
lbtno problems - it turns out that the api accepted the lowercase username to make the changes10:09
lbthowever the script pulls back the usernames and it returns the correct uppercase one10:09
lbtbut when it compares it to the yaml it sees Thaodan should not be there but thaodan should so.. it removes Thaodan and adds thaodan via the API...10:10
lbtso I suppose the script could do a case-insensitive compare ... but ...10:10
lbtanyhow... now I need to see why I can't send jolla.com emails10:11
*** Ischwitch is now known as Ingvix12:57
*** monich_ is now known as monich17:45
lbtPSA: services will be down for a bit - replacing a failed drive - back soon19:37
Thaodanlbt: Sorry to break your service, I was wondering if I should use Thaodan instead of thaodan but all names in the file where lowercase21:57

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