| mal | Oksana: usually browser has several dependencies which would have to be built and in some cases those can bring even more dependencies | 00:48 |
|---|---|---|
| *** zbenjamin is now known as Guest3976 | 02:06 | |
| *** zbenjamin_ is now known as zbenjamin | 02:06 | |
| dcaliste | Hello chriadam, is it possible to shift our meeting of 20-30 minutes ? | 07:53 |
| chriadam | hi dcaliste yes no problem | 07:53 |
| dcaliste | Thanks see you in then. | 07:54 |
| dcaliste | Hello again chriadam, sorry for the delay. | 08:30 |
| chriadam | hi dcaliste no problem at all | 08:30 |
| chriadam | I hope you had a good week? | 08:31 |
| dcaliste | Not the best I've ever known. Doesn't matter. | 08:32 |
| dcaliste | Thinking 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 |
| dcaliste | Both of us have changed the code in nemo-qml-plugin-calendar not to duplicate the notebook color in GSetting. | 08:34 |
| dcaliste | I still think it's a good idea. Like that everywhere else the notebook color relies only on the notebook color attribute. | 08:35 |
| dcaliste | But the question is legitimate and after some thoughts on it, I think it's a sync problem, not a plateform issue. | 08:35 |
| chriadam | I wonder if we can mark color as "if changed by user, don't overwrite with server value" | 08:37 |
| chriadam | during downsync step | 08:37 |
| chriadam | but 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 |
| dcaliste | Indeed, it's on the sync action that the color gets changed. My solution is thus this one : | 08:37 |
| dcaliste | flag 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 |
| dcaliste | Like that you can override the color on device and if you affect a new one on server it is propagated. | 08:38 |
| dcaliste | I didn't have time to create a patch with this, but the code would be quite simple with notebook properties. | 08:39 |
| dcaliste | What do you think ? | 08:39 |
| chriadam | I'm not entirely certain I understand the proposal. is this adding a new field to the notebook table? | 08:40 |
| dcaliste | No, just a custom property. | 08:41 |
| dcaliste | something like notebook->setCustomProperty(SERVER_COLOR, color); | 08:42 |
| chriadam | so 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 |
| dcaliste | Yes we write something like : | 08:42 |
| dcaliste | if (notebook->customProperty(SERVER_COLOR) != color) | 08:43 |
| dcaliste | { | 08:43 |
| dcaliste | notebook->setCustomProperty(SERVER_COLOR, color); | 08:43 |
| dcaliste | notebook->setColor(color); | 08:43 |
| dcaliste | } | 08:43 |
| dcaliste | So 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 |
| chriadam | makes sense, yes | 08:45 |
| chriadam | but | 08:45 |
| chriadam | if the server side color doesn't change | 08:45 |
| chriadam | (but the client has changed the color locally) | 08:46 |
| chriadam | won't that if check still "match"? | 08:46 |
| chriadam | oh, no ignore me | 08:46 |
| dcaliste | Sorry 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 |
| chriadam | the "color" in that check is the server one | 08:46 |
| chriadam | yes | 08:46 |
| chriadam | sorry, my bad | 08:46 |
| chriadam | I agree, that sounds good. | 08:47 |
| dcaliste | It'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 |
| chriadam | I agree. | 08:48 |
| chriadam | I'm happy to implement in google+exchange | 08:49 |
| chriadam | etc | 08:49 |
| dcaliste | I should be able to find time this week to create a MR with this idea for CalDAV part. | 08:49 |
| chriadam | tyvm | 08:50 |
| dcaliste | I'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 |
| chriadam | well, perhaps he's not available currently | 08:56 |
| chriadam | I will poke him tomorrow, and merge / tag it to master if no concerns | 08:56 |
| dcaliste | Thank you. | 08:56 |
| chriadam | I didn't get a chance to review the buteo-syncfw MR#59 any further, unfortunately | 08:57 |
| chriadam | I have spent today and yesterday looking into the QMF upstream things | 08:57 |
| dcaliste | Sorry, 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 |
| dcaliste | I'll try not to forget it this week also. | 08:57 |
| dcaliste | How about QMF ? It's a huge task :/ | 08:58 |
| chriadam | I 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 |
| chriadam | well, most of the unit tests are passing, just two left for me to fix | 08:58 |
| chriadam | from there, need to figure out state -- might be able to at least get things integrating, not sure. | 08:58 |
| chriadam | I think next week we should discuss further the next steps on that front :-) | 08:59 |
| dcaliste | Ok, then, I can create the reverting patch for what is still necessary to compile back on 5.6 for Sailfish. | 08:59 |
| chriadam | I'll poke pvuorela again also about your qtbase PR | 09:00 |
| dcaliste | Thank you for working on this upgrade, it's very important not to pile up too many downstream patches. | 09:00 |
| chriadam | yeah, definitely. I'm glad to be able to work on it, got given the green light by Pekka so is good :-) | 09:00 |
| chriadam | I have a couple of QtPIM patches which need to get integrated also IIRC, once we're done with QMF | 09:01 |
| dcaliste | You 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 |
| chriadam | thanks, 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 that | 09:02 |
| chriadam | thanks 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 side | 09:03 |
| dcaliste | No problem, you have to work on many thing else also ! | 09:03 |
| chriadam | was there any other PRs which I might have forgotten about and need attention from our side? | 09:04 |
| chriadam | from what I can see, the caldav one I will merge this week, the qtbase one I hope pvuorela merges this week | 09:04 |
| chriadam | then there's the buteo-syncfw one which needs more review/testing and I'd like flypig to look into that also | 09:04 |
| pvuorela | yea, i'll do it. just wanted to avoid during the releasing going on. | 09:05 |
| pvuorela | (hi) | 09:05 |
| dcaliste | That's it, pvuorela mentioned also last week that the cutom timed alarms should not apply to recurring event. Hello pvuorela ! | 09:05 |
| dcaliste | I agree on this, didn't think about it before but it makes sense not to have it in that case. | 09:06 |
| chriadam | pvuorela: true, that's a good point - maybe I should hold off on the caldav PR merge also, then? | 09:06 |
| dcaliste | So there's https://bitbucket.org/jolla/ui-jolla-calendar/pull-requests/290 to address this. | 09:06 |
| pvuorela | chriadam: nah, doesn't matter on small ones, but qtbase will rebuild so many depending things. | 09:06 |
| chriadam | true true | 09:06 |
| pvuorela | dcaliste: thanks for the fix, need to check more closely, but seemed good. | 09:08 |
| dcaliste | Yes 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 |
| pvuorela | the visibility could be one thing. page visible false will change visibility of children. | 09:10 |
| dcaliste | Thank you chriadam, I think that's all for today, already had a good bunch of MR discussed. Thank you. | 09:11 |
| chriadam | dcaliste: 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 |
| flypig | Sorry for missing the meeting, I only just got here. | 09:12 |
| flypig | Just in asnwer to your previous comment, the buteo#76 PR was fine for me too. I think we should merge it. | 09:13 |
| chriadam | flypig: thanks | 09:14 |
| flypig | And I'll take a look at the butoe-syncfw!59 PR. Apologies for not already having done so. | 09:15 |
| dcaliste | flypig, 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 |
| chriadam | thanks everyone | 09:16 |
| * chriadam -> home, gnight | 09:16 | |
| dcaliste | This MR is a long shot one in fact. It's to prepare the buteo logging UI. | 09:16 |
| flypig | Okay, nice. | 09:17 |
| dcaliste | At 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 |
| mighty17 | Hi | 13:43 |
| 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 |
| ccerne | Hi! 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 |
| ccerne | To 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 |
| mal | ccerne: have you tried enabling both --enable-debug and --enable-trace? | 22:22 |
| mal | ccerne: 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 ./MyHybrisApp | 22:41 |
| ccerne | and yes, I have both --enable-debug and --enable-trace | 22:41 |
| *** nyov is now known as Guest53272 | 22:44 | |
| mal | ok, not sure why it's not printing anything, need to check if there is some arch limitations | 23: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 |
| ccerne | Stepping 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 wrong | 23:50 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!