Tuesday, 2021-02-09

malOksana: usually browser has several dependencies which would have to be built and in some cases those can bring even more dependencies00:48
*** zbenjamin is now known as Guest397602:06
*** zbenjamin_ is now known as zbenjamin02:06
dcalisteHello chriadam, is it possible to shift our meeting of 20-30 minutes ?07:53
chriadamhi dcaliste yes no problem07:53
dcalisteThanks see you in then.07:54
dcalisteHello again chriadam, sorry for the delay.08:30
chriadamhi dcaliste no problem at all08:30
chriadamI hope you had a good week?08:31
dcalisteNot the best I've ever known. Doesn't matter.08:32
dcalisteThinking about this one : https://forum.sailfishos.org/t/4-0-1-45-ea-caldav-custom-colors-get-lost-on-sync/4657, I would like to propose you the following solution:08:33
dcalisteBoth of us have changed the code in nemo-qml-plugin-calendar not to duplicate the notebook color in GSetting.08:34
dcalisteI still think it's a good idea. Like that everywhere else the notebook color relies only on the notebook color attribute.08:35
dcalisteBut the question is legitimate and after some thoughts on it, I think it's a sync problem, not a plateform issue.08:35
chriadamI wonder if we can mark color as "if changed by user, don't overwrite with server value"08:37
chriadamduring downsync step08:37
chriadambut not sure how to detect that case (i.e. was it changed by user, or was the value just the "old" value from the server, which SHOULD be updated to the new server value)08:37
dcalisteIndeed, it's on the sync action that the color gets changed. My solution is thus this one :08:37
dcalisteflag the notebook with a property containing the last server color. Apply the server color only on first sync and when the server color changes.08:38
dcalisteLike that you can override the color on device and if you affect a new one on server it is propagated.08:38
dcalisteI didn't have time to create a patch with this, but the code would be quite simple with notebook properties.08:39
dcalisteWhat do you think ?08:39
chriadamI'm not entirely certain I understand the proposal.  is this adding a new field to the notebook table?08:40
dcalisteNo, just a custom property.08:41
dcalistesomething like notebook->setCustomProperty(SERVER_COLOR, color);08:42
chriadamso the value of this custom property would be written to during downsync, if it changes server side.  does it ever "propagate" to the normal "color" field?08:42
dcalisteYes we write something like :08:42
dcalisteif (notebook->customProperty(SERVER_COLOR) != color)08:43
dcalistenotebook->setCustomProperty(SERVER_COLOR, color);08:43
dcalisteSo on first sync the server color is set locally. Then the user is free to choose on device the calendar color, but if he changes it on server the change is applied on device also.08:44
chriadammakes sense, yes08:45
chriadamif the server side color doesn't change08:45
chriadam(but the client has changed the color locally)08:46
chriadamwon't that if check still "match"?08:46
chriadamoh, no ignore me08:46
dcalisteSorry I forgot to mentioned that color variable in the above code is actually the server color as received from the server on downsync.08:46
chriadamthe "color" in that check is the server one08:46
chriadamsorry, my bad08:46
chriadamI agree, that sounds good.08:47
dcalisteIt's very simple changes, the only downside is that we need to implement it in every sync plugin... But as I said I think it's a sync issue, so.08:47
chriadamI agree.08:48
chriadamI'm happy to implement in google+exchange08:49
dcalisteI should be able to find time this week to create a MR with this idea for CalDAV part.08:49
dcalisteI've been using https://git.sailfishos.org/mer-core/buteo-sync-plugin-caldav/merge_requests/76 for a week now. I didn't do any large modification to my calendar, simply editing or adding new entries, but nothing breaks beside the first sync as mentioned in the comments.08:52
chriadam@flypig: were you happy with that one?  I didn't have any concerns with it other than those we already discussed.  I feel like we should probably get it into devel sooner rather than later, to maximise testing...08:53
chriadamwell, perhaps he's not available currently08:56
chriadamI will poke him tomorrow, and merge / tag it to master if no concerns08:56
dcalisteThank you.08:56
chriadamI didn't get a chance to review the buteo-syncfw MR#59 any further, unfortunately08:57
chriadamI have spent today and yesterday looking into the QMF upstream things08:57
dcalisteSorry, I forgot to address your comment https://git.sailfishos.org/mer-core/buteo-syncfw/merge_requests/59#note_67420 You're right, I should add the old matching code there.08:57
dcalisteI'll try not to forget it this week also.08:57
dcalisteHow about QMF ? It's a huge task :/08:58
chriadamI have a few patches to fix things in QMF (unit test fixes, some patches to actual code in qmail* stuff - a crash fix, an endless loop fix, and now working on a reference stability one)08:58
chriadamwell, most of the unit tests are passing, just two left for me to fix08:58
chriadamfrom there, need to figure out state -- might be able to at least get things integrating, not sure.08:58
chriadamI think next week we should discuss further the next steps on that front :-)08:59
dcalisteOk, then, I can create the reverting patch for what is still necessary to compile back on 5.6 for Sailfish.08:59
chriadamI'll poke pvuorela again also about your qtbase PR09:00
dcalisteThank you for working on this upgrade, it's very important not to pile up too many downstream patches.09:00
chriadamyeah, definitely.  I'm glad to be able to work on it, got given the green light by Pekka so is good :-)09:00
chriadamI have a couple of QtPIM patches which need to get integrated also IIRC, once we're done with QMF09:01
dcalisteYou can add me if you need reviews for your QtPIM. Not that I know much about this code, but if it helps, don't hesitate.09:02
chriadamthanks, I will do.  I think it's just a couple of "upstream our patches" cases which weren't integrated for some build-system related issue, need to investigate and find out why and then fix that09:02
chriadamthanks as always for your willingness to help, and your proactivity.  it really is greatly appreciated, even if I'm sometimes slow to push things along from my side09:03
dcalisteNo problem, you have to work on many thing else also !09:03
chriadamwas there any other PRs which I might have forgotten about and need attention from our side?09:04
chriadamfrom what I can see, the caldav one I will merge this week, the qtbase one I hope pvuorela merges this week09:04
chriadamthen there's the buteo-syncfw one which needs more review/testing and I'd like flypig to look into that also09:04
pvuorelayea, i'll do it. just wanted to avoid during the releasing going on.09:05
dcalisteThat's it, pvuorela mentioned also last week that the cutom timed alarms should not apply to recurring event. Hello pvuorela !09:05
dcalisteI agree on this, didn't think about it before but it makes sense not to have it in that case.09:06
chriadampvuorela: true, that's a good point - maybe I should hold off on the caldav PR merge also, then?09:06
dcalisteSo there's https://bitbucket.org/jolla/ui-jolla-calendar/pull-requests/290 to address this.09:06
pvuorelachriadam: nah, doesn't matter on small ones, but qtbase will rebuild so many depending things.09:06
chriadamtrue true09:06
pvuoreladcaliste: thanks for the fix, need to check more closely, but seemed good.09:08
dcalisteYes thank you. Yep, playing with visibility, there could always be corner cases. I tried to think in advance to some, but I may have missed others. Thanks for checking this closely, indeed.09:09
pvuorelathe visibility could be one thing. page visible false will change visibility of children.09:10
dcalisteThank you chriadam, I think that's all for today, already had a good bunch of MR discussed. Thank you.09:11
chriadamdcaliste: I had nothing else either.  thanks for your time and effort as always.  I hope this week is better than last week for you!09:12
flypigSorry for missing the meeting, I only just got here.09:12
flypigJust in asnwer to your previous comment, the buteo#76 PR was fine for me too. I think we should merge it.09:13
chriadamflypig: thanks09:14
flypigAnd I'll take a look at the butoe-syncfw!59 PR. Apologies for not already having done so.09:15
dcalisteflypig, really no problem. And I just noticed that I didn't address a comment from chriadam there neither :/ I'll do it during the week.09:16
chriadamthanks everyone09:16
* chriadam -> home, gnight09:16
dcalisteThis MR is a long shot one in fact. It's to prepare the buteo logging UI.09:16
flypigOkay, nice.09:17
dcalisteAt the moment, disabled accounts still start the sync for the associated profile, and then quick return. So these are in the logs and it look strange to see a sync action for a disabled account.09:17
thigg[m]Hi, are there hints if there is going to be another ea-release, or is the current release going live?15:41
thigg[m](guess thats been asked already 43 times...)15:42
ccerneHi! Does anyone know of a good way to get trace statements working on libhybris? Unfortunately, --enable-trace with autogen.sh does not appear to work. For context, I am trying to debug a crash that happens in libhyrbis when it tries to execute the DT_INIT_ARRAY functions.21:38
ccerneTo expand on my question, I noticed the hybris README does not have support for x86/x86_64. I was able to get some simple NDK-compiled C functions running on x86 and x86_64, but the library I have crashes on the platform (it uses gles, not sure if that's part of the problem)21:40
malccerne: have you tried enabling both --enable-debug and --enable-trace?22:22
malccerne: what environmental variables did you set when you tried to get the traces?22:23
ccerne@mal: HYBRIS_TRACE=1 HYBRIS_LOGGING_LEVEL=debug HYBRIS_LD_DEBUG=1 ./MyHybrisApp22:41
ccerneand yes, I have both --enable-debug and --enable-trace22:41
*** nyov is now known as Guest5327222:44
malok, not sure why it's not printing anything, need to check if there is some arch limitations23:25
ccerne@mal: I do get some output, but nothing from the TRACE statements (just from the debug statements). Both on x86 and x86_64.23:37
ccerneStepping through GDB, it seems one of the issues is that operator.new in the binary I'm trying to load is returning 1, which isn't a valid memory address. Will do some more digging, but maybe I configured libhybris wrong23:50

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