| *** zbenjamin is now known as Guest71552 | 01:25 | |
| *** zbenjamin_ is now known as zbenjamin | 01:25 | |
| *** nyov is now known as Guest67703 | 03:03 | |
| chriadam | afk a few mins | 07:17 |
|---|---|---|
| dcaliste | Hello chriadam, sorry to be late today. | 07:23 |
| chriadam | hi dcaliste, no problem | 07:28 |
| chriadam | I hope you had a good week! | 07:28 |
| dcaliste | It's fine, I'm put on vacation by my employer and take time to do gardening or fixing things in the house. I hope it was alright for you also. | 07:29 |
| dcaliste | Thanks for the merged MR in CalDAV. | 07:29 |
| dcaliste | In the context of nemo-qml-plugin-calendar!55 https://git.sailfishos.org/mer-core/nemo-qml-plugin-calendar/merge_requests/55, maybe we can discuss a bit https://git.sailfishos.org/mer-core/buteo-sync-plugins-social/merge_requests/58 | 07:30 |
| dcaliste | It is saving the Buteo profile id in the mkcal notebook for Google calendars. | 07:31 |
| chriadam | sure | 07:32 |
| chriadam | so, that one now unconditionally sets the email address to ownerEmail parameter (but that parameter is only set in the case where the access role = owner for the calendar?) | 07:34 |
| chriadam | and also sets the syncProfile for the notebook appropriately | 07:34 |
| chriadam | I haven't tested, but it seems good to me | 07:34 |
| dcaliste | I don't think so, hopefully I didn't change the behaviour when factorizing the email prop with the sync profile one. | 07:34 |
| chriadam | I think it should be functionally equivalent yes | 07:35 |
| chriadam | will have to test, but code LGTM | 07:35 |
| dcaliste | When email is empty in the setCalendarProp() func, the behaviour of the mkcal function is to remove the custom property. | 07:35 |
| dcaliste | And the email is non empty only if the user is owner of the calendar upstream. | 07:36 |
| dcaliste | See line 2295. | 07:36 |
| chriadam | makes sense. | 07:36 |
| chriadam | the "remove if empty" semantic of setCalendarProp() was something I had forgotten | 07:37 |
| dcaliste | I had to check it myself also ;) | 07:37 |
| chriadam | thanks for that one - I guess that's the last thing preventing merge of nqpc#55 | 07:38 |
| dcaliste | My concern is a bit about the fact that I need to take the profile id from an account setting, while it is provided to the plugin as argument... | 07:39 |
| dcaliste | But this argument is lost in the various layers we go through to arrive at the googlesyncadaptorcalendar. | 07:39 |
| dcaliste | In practice, I think it's not really an issue since this setting is set by the account helper in the buteo daemon. | 07:40 |
| chriadam | yeah the buteo-sync-plugins-social is a bit of a mess, as it's a refactor from old sociald into buteo plugins | 07:40 |
| chriadam | lots of unnecessary layers exist there now for historical reasons unfortunately | 07:40 |
| dcaliste | I forgot to append "at account creation" in my last sentence... | 07:41 |
| dcaliste | Do you think it is worth to propagate the profile id in all the sociald layers, or it's too invasive ? | 07:41 |
| dcaliste | If it has to be used by other calendar adaptors, it may be worth, but if only Google is concerned, I think the MR is simpler like that. What do you think ? | 07:42 |
| dcaliste | Oh, I forgot, I still didn't test it on device though... It looks simple enough, but that's usualy the kind of sentence that makes things misbehave ! | 07:43 |
| chriadam | I think only Google matters at this point, but I can take a look (e.g. potentially VK also but haven't tested for a while) | 07:46 |
| chriadam | but yes, no problem, I will test it with nqpc55 to make sure it all works as expected | 07:46 |
| dcaliste | Ok, thank you. Don't hesitqte to mail me or ping me on IRC if I need to save this profile_id somewhere else. | 07:47 |
| chriadam | one unrelated question I had about the caldav discovery MR: after merging, I realised that I had forgotten to check: if the user has selected specific calendars to sync during account creation, will that selection still be observed/honoured by the caldav plugin? | 07:47 |
| dcaliste | Hopefully yes ;) | 07:47 |
| chriadam | cool ;-) I'll check that too | 07:47 |
| dcaliste | Well, yes for sure in fact. I'm using this configurqtion myself. | 07:47 |
| chriadam | excellent | 07:48 |
| dcaliste | Have several calendars online (most for testing playground) but only sync two of them. | 07:48 |
| chriadam | great | 07:49 |
| dcaliste | What is ignored by the code now in the main line (not in the fallback case) is the cache list of upstream calendars. The enaled list is still used to actually do the sync process. | 07:49 |
| chriadam | aside from that - I haven't had a chance to check the messaging framework one properly yet | 07:49 |
| dcaliste | No problem, it's just about silencing warnings, not very important. | 07:50 |
| chriadam | flypig is trackign down the tzset() issue from calendar side | 07:51 |
| chriadam | but I believe he will merge that mkcal PR asap | 07:51 |
| dcaliste | Great job from him, indeed. | 07:51 |
| dcaliste | Not easy at all to find the root problem of his display issue. | 07:52 |
| chriadam | err, kcalcore I mean | 07:52 |
| chriadam | yes! | 07:52 |
| chriadam | definitely a rabbit hole | 07:52 |
| dcaliste | When you have time at Jolla, there are two features that maybe could be moved forward a bit now that 3.3.0 is EA : | 07:53 |
| dcaliste | https://git.sailfishos.org/mer-core/libcommhistory/merge_requests/36 about listing activity for unsaved contacts. | 07:54 |
| dcaliste | and https://git.sailfishos.org/mer-core/nemo-qml-plugin-calendar/merge_requests/51 adding time zone support for the UI. | 07:54 |
| dcaliste | In both MR, it remains unsolved discussions. Like for the latter, discussions about proper naming for additional properties taking the timezone into account. | 07:55 |
| chriadam | thanks, I will raise those internally and we will see what we can do | 07:55 |
| dcaliste | Thank you for this :) | 07:56 |
| chriadam | pinged mschuele about those ones | 07:57 |
| chriadam | hopefully we will be able to progress these in the next couple of weeks, before 3.4.0 branches | 07:58 |
| dcaliste | That sounds great. I agree that these MRs cannot be merged as is yet. But the minor improvements they bring are worth the work to polish them properly I think. | 07:59 |
| chriadam | dcaliste: btw flypig just mentioned that he will respond to you regarding nqpc MR#55 shortly | 07:59 |
| chriadam | he just has a full plate currently | 08:00 |
| dcaliste | Ok, that's nice from him, but no need to rush from his side, I still have a lot of gardening and house fixing in my todo list ;) | 08:00 |
| chriadam | forced vacation is never optimal, but it certainly gives opportunity to make the gardens nice ;-) | 08:01 |
| dcaliste | Particularly in spring time, like we are now in the northern hemisphere. | 08:02 |
| chriadam | :-) | 08:02 |
| chriadam | I had nothing else to discuss this week - did you have any other topics you wanted to cover? did I forget anything from last week? | 08:02 |
| dcaliste | Thank you Chris for the meeting today. Sorry again to be late. I think we discussed all points. | 08:03 |
| chriadam | no problem at all, thank you for your time and effort as always! | 08:03 |
| chriadam | have a great week! | 08:03 |
| dcaliste | You too. | 08:03 |
| *** frinring_ is now known as frinring | 09:11 | |
| Ingvix | it appears my devicelock code got messed up somehow when I resized my file systems in recovery mode. The correct code no longer works. e2fsck found bunch of stuff to fix and I just yessed everything so I guess that somehow affected the device lock, maybe. Is the only option to reset to factory or reinstall sfos? | 10:40 |
| Ingvix | it would not be big loss since I just got the device recently but a bit annoying to set things up again | 10:42 |
| Ingvix | apparently reflashing is the only way in the case of lost devicelock code | 10:44 |
| Ingvix | now I got no devicelock code set but it asks for a code at boot. I can get to recovery shell without problems. Can I set or remove the current encryption password there? | 12:18 |
| *** svartoyg_afk is now known as svartoyg | 15:15 | |
| flipper-maniac | hi, is there anyway to change to another application pressing the camera button on a XA2. Maybe a patch? | 17:09 |
| Ingvix | flipper-maniac, no, you can't currently change the physical button actions | 18:04 |
| Ingvix | it's a bit of a shame really, you could do so much with them if you bind your own actions to them | 18:06 |
| flipper-maniac | ok thank you for the answer Ingvix | 18:15 |
| tanriol | atlochowski: About the GPS timing problem: the difference between the real date and the track date looks like 1024 weeks, which is the period of the GPS week number rollover. Sounds like some component is decoding the GPS time in the previous period. | 19:48 |
| mal | interesting | 19:55 |
| mal | I need to have a look | 19:55 |
| attah | Rollover was last year... so the issue should have been around for a while then? | 19:59 |
| mal | tanriol: where do you see the issue? | 20:08 |
| tanriol | mal: This was a reply to messages from atlochowski around 2020-04-20T06:40UTC in this channel. It's their problem, not mine. | 20:15 |
| mal | ah | 20:17 |
| mal | I thought you had tested it also | 20:18 |
| mal | I captured a gps log on jolla c using osm scout and the log seems to have correct timestamps | 20:19 |
| atlochowski | mal: on my Jolla C everything is ok but on my Jolla 1 not. and I'm not the only one https://together.jolla.com/question/225700/wrong-date-from-gps-on-jolla-1/ | 21:05 |
| atlochowski | mal: and this is the reason why I notices that couple days ago "Ups. In recent release of OSM Scout, I just changed time source for from new Date() (current device time) to Position.timestamp (time from GPS position event)." | 21:08 |
| atlochowski | attah: and this is the reason why I notices that couple days ago "Ups. In recent release of OSM Scout, I just changed time source for from new Date() (current device time) to Position.timestamp (time from GPS position event)." | 21:11 |
| mal | maybe that could be solved using some hack to add a constant value in the gps middleware to the timestamp coming from gps hardware | 21:22 |
| mal | atlochowski is the value otherwise reasonable, I mean if some contant would be added to it | 21:24 |
| *** Ischwitch is now known as Ingvix | 22:02 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!