Tuesday, 2020-01-21

*** zbenjamin_ is now known as zbenjamin02:28
dcalisteHello chriadam, how are you ?08:02
chriadamhi dcaliste, I'm well thanks - how are you?08:03
dcalisteFine, thank you. I was skying yesterday and didn't reply to your comments on the MR#70 in settings-accounts… By the way, thanks for the merged fixes in CalDAV.08:05
chriadamdcaliste: no worries, thank you.  Oh, just for future reference - I didn't know this, but apparently the CI gate now accepts "Contributes to TJC#123456" commits now also, so I don't need to create MER# bugs in future :-)08:06
chriadamI didn't get a chance to progress the mkcal PR (and related nemo PR) for all day events stored with tz08:08
chriadamhopefully will get a chance this week08:08
dcalisteAh, nice. About MR#70, the problem with empty calendars is that we're not sure that we're at the right address. In CalDAV, the code to list calendars is really crude and rely on a known path (deduced from existing calendars).08:08
dcalisteSo, having no calendar won't help in CalDAV because I didn't add the discovery code that exist in settings.08:09
chriadamright.  I guess one issue is that there's no way (currently) for the caldav plugin to report the issue to the UI if the path is wrong or calendars couldn't be discovered etc.. probably that's why we did it in the accounts UI flow in the first place, I guess08:09
chriadamdcaliste: btw there is a (bsd? or lgpl at least?) licensed copy of that code in the cdavtool in carddav repo08:10
chriadamif that is useful can copy to caldav plugin08:10
dcalisteAh, nice to know, because I didn't want to add the discovery code because I read it already from the proprietary bits in settings, and rewrite it from scratch and RFC would have been a big pile of work.08:11
dcalisteAyway, for the moment, in MR#70, there are two fixes in my opinion:08:12
dcaliste- first report an error if no calendar can be found at the given path (poor solution but better than leting the account be created but going nowhere with it),08:13
dcaliste- second, report the CalDAV discovery errors to the user.08:13
chriadamI agree08:15
dcalisteAbout the second point, the removal of the signal is motivated by the fact that onAccountCreationError handler is only present in AccountCreationDialog.qml that is not used in CalDAV UI.08:15
dcaliste(I think that even pvuorela removed it in MR#71 because it is not used anymore)08:16
chriadamah, interesting, makes sense.  blam knows more of the UI side stuff than I do.  glad pvuorela did a bit cleanup there too.08:16
dcalisteSee https://bitbucket.org/jolla/ui-jolla-settings-accounts/commits/d08c167d6d09679e0a7dd0205b447ed0c937918008:16
chriadamregarding the error reporting - the discovery error reporting should (hopefully) already exist to some extent in the accounts flow already, right (so should be mostly re-usable for this case).  for the second - caldav plugin errors etc is a larger topic, IMO not necessary at this stage to complete08:17
dcalisteWell MR#70 addresses both. The first point is easy by adding a new zerror enum entry, the second is simply to use the infoDescription. It's almost a one liner.08:19
chriadamoh, still in the accounts flow - yes, sorry I misunderstood (thought you meant from the buteo plugin)08:19
chriadamI'll have to recheck that MR but it seemed good to me - but would prefer blam or pvuorela approve that as it's been a while since I touched any of that code08:20
chriadamthanks very much for that08:20
chriadamunrelated question: did you see kcalcore MR#14 by any chance?08:20
chriadamwondering if you had an opinion about that.  at this stage, I'm not planning to dig any deeper, as the workaround seems to resolve the issue from the perspective of the unit test and the sync plugin case (exchange) where we hit that, but I guess the real problem is somewhere in the formatting of the VTIMEZONE data from the mstz struct spec, in libical08:22
chriadamif you're happy with the workaround, I'll merge and tag that one08:22
dcalisteYes, but I didn't have time yet to look at it closely, sorry. The same applies for flypig MRs about folder sync… I'll try to do it tomorrow or on Friday.08:22
dcalisteAbout MR#14, I'll give a better look today.08:23
dcalisteBy the way, pvuorela, do you have a moment to discuss deprecated code in settings-accounts ? After your MR#71, I think some signals still remains but will have no effect.08:24
chriadammight not be in the office yet08:28
chriadamcould email him or just comment to MR#71 with those findings :-)08:28
chriadamI know he's merged but it shoudl still send notifications etc08:28
dcalisteOk, I will comment there.08:29
dcalisteI would like to mention also https://git.sailfishos.org/mer-core/buteo-sync-plugin-caldav/merge_requests/34 to your attention.08:30
dcalisteIt's a very old one, that I revamp recently.08:30
chriadamah, thank you08:31
chriadamI wonder if I need something similar in google plugin?08:31
chriadamchange LGTM, I will have to check the unit test carefully to make sure it's testing what I think it's testing08:31
chriadambut hopefully will merge that one this week - thank you very much08:32
dcalisteI don't know if google plugin is using a ctag-like solution instead of retrieving all etags in a window span ?08:32
dcalisteThe ctag route makes this kind of changes useless.08:32
chriadamit has switched to using ctag-like solution recently, but falls back to a "span window" in some cases, which now that I think about it should only be clean-sync case, so shouldn't affect08:32
dcalisteGoing the ctag-route in CalDAV is in my todo list for 2020 ;) Would help https://together.jolla.com/question/216183/caldav-401-problem/08:34
dcalisteHello pvuorela.08:34
pvuoreladcaliste: some specific signals? might have easily left something, just noticed a lot of dead code and tried to remove it as much as possible :)08:34
dcalisteIf you look into the google.qml and friends in settings-account, you will see the onAccountCreationError that is supposed to deal with the error message for the user.08:34
dcalisteGrep for onAccountCreationError to see where the handle is.08:35
dcalisteIt was in AccountCreationDialog.qml that has been removed (for reason of not being used).08:35
dcalisteSo I'm afraid the error message is going no where.08:35
dcalisteI may be wrong though and is missing something.08:36
dcalistechriadam, I've continued to work on QML binding inside Buteo. It's working nicely. I've added as a QVariantMap the keys / values from the profile.08:37
dcalisteI still need to look at the sync schedule binding, and for the read-only access (no modification to be done), it's working nicely. I'm using my little UI page to follow the logsgoing on for my sync accounts and it's pretty usefull.08:38
pvuoreladcaliste: quickly appearing it wasn't used before my removals either, right?08:38
dcalistepvuorela, right.08:38
dcalisteWhich brings me to MR#70 for CalDAV, to report such message to the user.08:39
dcalisteBut I'm afraid there might be the same problem for the other account types.08:39
chriadamdcaliste: sounds liek great progress.  I'm not sure whether we have bandwidth internally to review that code currently (buteo QML bindings are not currently needed for customer-approved work, even though displaying sync results to UI has been long-time goal for us)08:40
dcalisteThese error message strings exist and are translated but they never appear. Which is sad, it would help the user to understand the problem, instead of just having the "Ooops" page.08:40
dcalistechriadam: ok, so I continue to work on it to add support for every useful things in profile from my side, and will come back with complete MR when you may have time to review. I'll try to make the QML addition as less intrusive as possible for existing code base.08:42
chriadamtyvm much appreciated08:42
pvuoreladcaliste: chriadam or bea could better know how that's really supposed to work, but do now wonder why there even is accountCreationError signal if it's not being used. like should that be also removed or deprecated.08:43
chriadamwondering if the error signal produces a translated string, or something which is more a developer error message08:44
chriadamif the latter, perhaps in the past was connected to some console.log for debugging purposes?  but seems strange that it wouldn't be used for a state transition (i.e. error has occurred, so transition to error state)08:45
chriadambut honestly don't remember, I will ask Bea about it tomorrow08:45
dcalisteIt's translated strings, at least for CalDAV, see declarative/caldavaccountcalendarupdater.cpp#65408:46
chriadamcurious.  so we should try to display those (below the "Oops" message or something perhaps08:47
chriadamthanks for raising it08:48
chriadamI will speak to Bea tomorrow and will discuss08:48
dcalistechriadam, indeed, and I think it was done in the AccountCreationDialog.qml, but this one has been deprecated in favour of AccountCreationPage.qml, that is not doing any thing about this signal.08:48
dcalisteSo the strings got lost at one point in the past, I guess.08:48
chriadamindeed :-(  thanks08:49
dcalisteI let you both discuss with Bea about this. If you don't have time to handle this, I may help.08:49
chriadamwas that all for discussion this week?  I had nothing else - have been busy chasing bugs in google calendar sync recently, unfortunately, so haven't spent much time on the outstanding kcalcore/mkcal/nemo-calendar PRs you have, sorry08:50
dcalistechriadam, no problem, I need to look also at your MRs and flypig ones. It's ok for me about the meeting, I think we discussed all points.08:51
chriadamcool.  thanks very much as always for your contributions!08:51
chriadamhave a great week, see you next Tuesday08:51
dcalisteYep, have a pleasant evening. See you.08:52
flypigdcaliste, a quick mention about the folder sync changes. I'm making some changes based on jpetrell's comments, so you may want to hold off looking until then. However, ideally we'd also like to have it merged by Thursday next week. Any comments you have would be appreciated.08:53
dcaliste@flypig, I'll give a look and try them on device tomorrow and on Friday.08:55
*** vilpan is now known as Guest5727908:55
flypigdcaliste, thank you, I'd really appreciate it. Given it's your contribution, I'd like to have your thought.08:57
flypig(one thought would be enough, but plural even better!)08:57
dcalisteIndeed ;) You should hear from myself tomorrow, I guess.08:59
*** Guest57279 is now known as vilpan09:09
adantesI guess I messed up badly with my sfos now09:44
adantesMy wifi router is buging lately, and I was o transfer files to my phone via scp, but it said it couldnt access to port 2209:45
adantesI went to developer mode, disabled and reanabled developer mode09:46
adantesit was takin forever to download developer pakages, so I quit the proccess, and rebooted wifi09:46
adantesNow, I can't enable developer mode. It says preparing changes and doesn't quit there09:47
adantesI really need to enable ssh access so I can access my files in the phone via wifi09:48
adantesIs there any tip you can give me?09:48
adantesXperia XA2, SFOS X latest build09:48
adantesXperia XA2 Ultra, SFOS X latest build09:48
*** frinring_ is now known as frinring10:08
x2sadantes: as stupid as it sounds, but did you try to reboot the phone already?10:25
adantesx2s: yes, of corse10:32
adantesI suppose something got corrupted10:33
adantestried utilities, refresh package registry, etc.10:33
x2sthen I'm out of ideas. I only mentioned this, because since the last update or the one before I have to reboot my phone sometimes when it comes out of flight mode, because it wont react to changes to the wifi anymore10:33
adantesno luck10:33
adantesjust restored factory defaults10:34
adantesI needed a fresh start on it anyway10:34
adantestnx anyway :+1:10:37
x2shaving to do a factory reset is somehow sad :/10:38
spiiroinadantes: have you edited usb-moded config files at some stage? developer mode should activate without noticeable delay -> getting ui to show those "preparing" banners for lengthy time -> usb-moded woes/crashing -> configs/binaries corrupted / out of sync with rest of sfos10:49
Herriemal: You around?12:28
malHerrie: yes12:33
Herriemal: Finally making some progress on Halium 8.1 got Android to start more or less in LXC after figuring out I was missing a vendor.img and busybox ;) Just now seems hwservicemanager on Android side doesn't start completely (i.e. hwservicemanager.ready doesn't get triggered). You have any idea how to debug that?12:37
maldoes strace show anything, assuming you can strace it?12:38
maluse 64-bit strace if needed12:39
HerrieWell I have logcat working12:39
HerrieAnd journalctl tells me it's starting hwservicemanager12:39
HerrieLot of things in logcat tell me they're waiting for hwservicemanager.ready12:40
malI would try to strace hwservicemanager to see what it is doing12:42
HerrieOK will give that a go12:43
HerrieApproach in Halium is a bit different with Android inside LXC, so a bit challenging at times, but can cherry-pick quite some things from mer-hybris in general :)12:44
malwondering what wayland versions should we keep supporting in libhybris, not sure what versions the OSes using libhybris have12:47
HerrieOn LuneOS side we keep updating to "latest & greatest" using Yocto mostly. We're on recent Qt, however some target devices are still stuck on 3.4 kernel & Android 5.1 base (though they could theoretically move to 7.1 without too much issues)12:51
malin sfos we have latest wayland12:52
mallibhybris has some code that has same things implemented that are now in wayland12:53
Herriemal: Best to check with Tofe at our end, he can tell you more for sure13:04
malHerrie: https://github.com/mlehtima/libhybris-1/commit/e3be14f5961d2826ccf4420911db8aa5b05236d513:14
adantesspiiroin: no, I guess I didn't.. but when I upgraded to sfos 3.2 for the first time, it showed me an error msg13:19
Herriemal: I'll check with Tofe and let you know13:20
adantestherefore, I was alsolooking for the need to put a fresh install13:20
adanteseverythings cool now, except for the lack of the android store icon13:20
adantesthat I'm still setuping the phone13:21
Herriemal: Checked with Tofe seems that we don't use Wayland < 1.15 at our end14:19
HerrieWe'd need to double check on actual targets, but we don't really see issues in your proposal14:20
malHerrie: that was just to be backwards compatible, really I would want to remove the whole wayland-egl.c from libhybris14:33
malHerrie: in case you want to see my whole cleanup branch https://github.com/mlehtima/libhybris-1/commits/cleanup still some small things to do14:35
Herriemal: Any idea how I can use LD_PRELOAD for hwservicemanager and strace at the same time?14:38
HerrieIf I "LD_PRELOAD=/android/system/lib64/libselinux_stubs.so" for hwservicemanager and then try to strace it I get: strace: error while loading shared libraries: libc++.so: cannot open shared object file: No such file or directory14:39
HerrieAh seems I can specify multiple .so's to LD_PRELOAD :)14:42
maldes the .so exist?14:46
Herriemal: Yeah if I preload hwservicemanager seems to not crash, but then I cannot strace it from within my ADB ;)14:50
HerrieWithout preloading the selinux stub it crashes. After preloading, it doesn't crash, but I cannot strace... So a bit catch 2214:52
HerrieIt complains that it cannot find libc++.so and a few others. Added all those and now strace will segfault ;)14:53
malHerrie: are you using 64-bit strace?15:09
HerrieHow do I know? Seems I only have 1 strace binary ;)15:10
malnot sure, I just have a separate one for 64-bit because sfos has only 32-bit strace15:11
x2sHerrie: do: file /usr/bin/strace15:14
x2sit will tell you15:14
HerrieWell on LuneOS side we don't have "file" command it seems15:19
HerrieBut pretty sure it's 64 bits15:19
x2sdo you have ldd?15:20
x2sthen try that. It will tell you against which libs strace is linked.15:20
HerrieNope also not15:22
HerrieBut when I LD_Preloaded the 32 bits one it was complaining15:22
HerrieThe 32 bits .so's from /lib folder15:22
HerrieWhen I did the 64 bits ones from lib64 it was not complaining, just segfaulting15:23
x2sWhat about strings /usr/bin/strace | head -n 1 ?15:24
HerrieYup that works ;) /lib/ld-linux-aarch64.so.115:24
HerrieSo 64 bits15:24
HerrieOk seems I'm missing some .so's that are critical in lib and lib64 (such as gralloc ones and other hardware ones...) Rebuilding....16:41
malHerrie: well that would explain some things :D16:44
Herriemal: Yeah, Halium relies on some of the .mk files in order to determine what to copy16:44
HerrieSometimes these vendor ones are not complete (as in this case)16:45
HerrieI switched to a 3.18 kernel device from 3.4 based Hammerhead to avoid old kernel specific issues, but get these instead ;)16:46
malHerrie: where did you get the newer kernel?16:55
malor do you mean you changed to some other device completely?16:55
malmaybe I misunderstood that16:56
Herriemal: Changed device completely16:58
HerrieLuckily with Halium it's not that much work most of the times ;)16:59
malok :)16:59
Herriemal: Advantage of Halium is that when there's a LineageOS port available, that it uses a standard approach for pretty much each target. So if we have a target that on Android 5.1 based and it has a 7.1 based port available, switching is easy.17:22
HerrieSo I can test our 7.1 targets pretty easily with WIP 8.1 just sometimes there are issues in vendor & proprietary repos17:22
HerrieBut 5.1 and 7.1 are old, so I'm working on 8.1 and 9.0 later.17:23
HerrieSo we can support some newer targets17:23
malHerrie: I should some day try to get sailfish running with halium, not sure if anyone did that17:25
Herriemal: Well the approach is different due to Android in LXC, but what we aim is to share the Android base across different devices, so we're not reinventing the wheel17:36
HerrieMer/SFOS and LuneOS share most of kernel defconfig anyway17:37
HerrieUBPorts has some specifics for AppArmor, Plasma Mobile is pretty similar as well17:37
HerrieNormally we can take a Mer defconfig and use it 1:1 or with only a few minor changes17:37
malHerrie: yes, probably doesn't need many changes in kernel side, sfos scripts probably need fixing17:39
Mister_Magistermal: or whoever https://git.merproject.org/mer-core/mce cert expired21:09
malMister_Magister: use git.sailfishos.org21:24
Mister_Magistermal: same thing21:24
Mister_Magisteror not21:24
malwhere do you build that?21:25
malfor me git.sailfishos.org works fine21:25
Mister_Magisteryea me too21:26
Mister_Magisterbut merproject.org is expired, is noone gonna do anything about it?21:26
malwell it was just noticed earlier this evening, maybe tomorrow when people are back at work21:28
malbut it's going being obsoleted anyway, it's just redirecting to git.sailfishos.org now21:29
pketogit.merproject.org cert updated, so redirects should work now, but what ever uses it should be pointed to git.sailfishos.org21:57

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