Tuesday, 2020-04-21

*** zbenjamin is now known as Guest7155201:25
*** zbenjamin_ is now known as zbenjamin01:25
*** nyov is now known as Guest6770303:03
chriadamafk a few mins07:17
dcalisteHello chriadam, sorry to be late today.07:23
chriadamhi dcaliste, no problem07:28
chriadamI hope you had a good week!07:28
dcalisteIt'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
dcalisteThanks for the merged MR in CalDAV.07:29
dcalisteIn 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/5807:30
dcalisteIt is saving the Buteo profile id in the mkcal notebook for Google calendars.07:31
chriadamso, 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
chriadamand also sets the syncProfile for the notebook appropriately07:34
chriadamI haven't tested, but it seems good to me07:34
dcalisteI don't think so, hopefully I didn't change the behaviour when factorizing the email prop with the sync profile one.07:34
chriadamI think it should be functionally equivalent yes07:35
chriadamwill have to test, but code LGTM07:35
dcalisteWhen email is empty in the setCalendarProp() func, the behaviour of the mkcal function is to remove the custom property.07:35
dcalisteAnd the email is non empty only if the user is owner of the calendar upstream.07:36
dcalisteSee line 2295.07:36
chriadammakes sense.07:36
chriadamthe "remove if empty" semantic of setCalendarProp() was something I had forgotten07:37
dcalisteI had to check it myself also ;)07:37
chriadamthanks for that one - I guess that's the last thing preventing merge of nqpc#5507:38
dcalisteMy 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
dcalisteBut this argument is lost in the various layers we go through to arrive at the googlesyncadaptorcalendar.07:39
dcalisteIn practice, I think it's not really an issue since this setting is set by the account helper in the buteo daemon.07:40
chriadamyeah the buteo-sync-plugins-social is a bit of a mess, as it's a refactor from old sociald into buteo plugins07:40
chriadamlots of unnecessary layers exist there now for historical reasons unfortunately07:40
dcalisteI forgot to append "at account creation" in my last sentence...07:41
dcalisteDo you think it is worth to propagate the profile id in all the sociald layers, or it's too invasive ?07:41
dcalisteIf 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
dcalisteOh, 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
chriadamI 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
chriadambut yes, no problem, I will test it with nqpc55 to make sure it all works as expected07:46
dcalisteOk, 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
chriadamone 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
dcalisteHopefully yes ;)07:47
chriadamcool ;-) I'll check that too07:47
dcalisteWell, yes for sure in fact. I'm using this configurqtion myself.07:47
dcalisteHave several calendars online (most for testing playground) but only sync two of them.07:48
dcalisteWhat 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
chriadamaside from that - I haven't had a chance to check the messaging framework one properly yet07:49
dcalisteNo problem, it's just about silencing warnings, not very important.07:50
chriadamflypig is trackign down the tzset() issue from calendar side07:51
chriadambut I believe he will merge that mkcal PR asap07:51
dcalisteGreat job from him, indeed.07:51
dcalisteNot easy at all to find the root problem of his display issue.07:52
chriadamerr, kcalcore I mean07:52
chriadamdefinitely a rabbit hole07:52
dcalisteWhen 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
dcalistehttps://git.sailfishos.org/mer-core/libcommhistory/merge_requests/36 about listing activity for unsaved contacts.07:54
dcalisteand https://git.sailfishos.org/mer-core/nemo-qml-plugin-calendar/merge_requests/51 adding time zone support for the UI.07:54
dcalisteIn both MR, it remains unsolved discussions. Like for the latter, discussions about proper naming for additional properties taking the timezone into account.07:55
chriadamthanks, I will raise those internally and we will see what we can do07:55
dcalisteThank you for this :)07:56
chriadampinged mschuele about those ones07:57
chriadamhopefully we will be able to progress these in the next couple of weeks, before 3.4.0 branches07:58
dcalisteThat 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
chriadamdcaliste: btw flypig just mentioned that he will respond to you regarding nqpc MR#55 shortly07:59
chriadamhe just has a full plate currently08:00
dcalisteOk, 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
chriadamforced vacation is never optimal, but it certainly gives opportunity to make the gardens nice ;-)08:01
dcalisteParticularly in spring time, like we are now in the northern hemisphere.08:02
chriadamI 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
dcalisteThank you Chris for the meeting today. Sorry again to be late. I think we discussed all points.08:03
chriadamno problem at all, thank you for your time and effort as always!08:03
chriadamhave a great week!08:03
dcalisteYou too.08:03
*** frinring_ is now known as frinring09:11
Ingvixit 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
Ingvixit would not be big loss since I just got the device recently but a bit annoying to set things up again10:42
Ingvixapparently reflashing is the only way in the case of lost devicelock code10:44
Ingvixnow 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 svartoyg15:15
flipper-maniachi, is there anyway to change to another application pressing the camera button on a XA2. Maybe a patch?17:09
Ingvixflipper-maniac, no, you can't currently change the physical button actions18:04
Ingvixit's a bit of a shame really, you could do so much with them if you bind your own actions to them18:06
flipper-maniacok thank you for the answer Ingvix18:15
tanriolatlochowski: 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
malI need to have a look19:55
attahRollover was last year... so the issue should have been around for a while then?19:59
maltanriol: where do you see the issue?20:08
tanriolmal: This was a reply to messages from atlochowski around 2020-04-20T06:40UTC in this channel. It's their problem, not mine.20:15
malI thought you had tested it also20:18
malI captured a gps log on jolla c using osm scout and the log seems to have correct timestamps20:19
atlochowskimal: 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
atlochowskimal: 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
atlochowskiattah: 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
malmaybe that could be solved using some hack to add a constant value in the gps middleware to the timestamp coming from gps hardware21:22
malatlochowski is the value otherwise reasonable, I mean if some contant would be added to it21:24
*** Ischwitch is now known as Ingvix22:02

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