| *** zbenjamin_ is now known as zbenjamin | 02:28 | |
| dcaliste | Hello chriadam, how are you ? | 08:02 |
|---|---|---|
| chriadam | hi dcaliste, I'm well thanks - how are you? | 08:03 |
| dcaliste | Fine, 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 |
| chriadam | dcaliste: 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 |
| chriadam | I didn't get a chance to progress the mkcal PR (and related nemo PR) for all day events stored with tz | 08:08 |
| chriadam | hopefully will get a chance this week | 08:08 |
| dcaliste | Ah, 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 |
| dcaliste | So, having no calendar won't help in CalDAV because I didn't add the discovery code that exist in settings. | 08:09 |
| chriadam | right. 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 guess | 08:09 |
| chriadam | dcaliste: btw there is a (bsd? or lgpl at least?) licensed copy of that code in the cdavtool in carddav repo | 08:10 |
| chriadam | if that is useful can copy to caldav plugin | 08:10 |
| dcaliste | Ah, 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 |
| chriadam | indeed | 08:12 |
| dcaliste | Ayway, 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 |
| chriadam | I agree | 08:15 |
| dcaliste | About 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 |
| chriadam | ah, interesting, makes sense. blam knows more of the UI side stuff than I do. glad pvuorela did a bit cleanup there too. | 08:16 |
| dcaliste | See https://bitbucket.org/jolla/ui-jolla-settings-accounts/commits/d08c167d6d09679e0a7dd0205b447ed0c9379180 | 08:16 |
| chriadam | regarding 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 complete | 08:17 |
| chriadam | indeed | 08:17 |
| dcaliste | Well 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 |
| chriadam | oh, still in the accounts flow - yes, sorry I misunderstood (thought you meant from the buteo plugin) | 08:19 |
| chriadam | I'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 code | 08:20 |
| chriadam | thanks very much for that | 08:20 |
| chriadam | unrelated question: did you see kcalcore MR#14 by any chance? | 08:20 |
| chriadam | wondering 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 libical | 08:22 |
| chriadam | if you're happy with the workaround, I'll merge and tag that one | 08:22 |
| dcaliste | Yes, 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 |
| dcaliste | About MR#14, I'll give a better look today. | 08:23 |
| chriadam | tyvm | 08:23 |
| dcaliste | By 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 |
| chriadam | might not be in the office yet | 08:28 |
| chriadam | could email him or just comment to MR#71 with those findings :-) | 08:28 |
| chriadam | I know he's merged but it shoudl still send notifications etc | 08:28 |
| dcaliste | Ok, I will comment there. | 08:29 |
| chriadam | ty | 08:29 |
| dcaliste | I would like to mention also https://git.sailfishos.org/mer-core/buteo-sync-plugin-caldav/merge_requests/34 to your attention. | 08:30 |
| dcaliste | It's a very old one, that I revamp recently. | 08:30 |
| chriadam | ah, thank you | 08:31 |
| chriadam | I wonder if I need something similar in google plugin? | 08:31 |
| chriadam | change LGTM, I will have to check the unit test carefully to make sure it's testing what I think it's testing | 08:31 |
| chriadam | but hopefully will merge that one this week - thank you very much | 08:32 |
| dcaliste | I don't know if google plugin is using a ctag-like solution instead of retrieving all etags in a window span ? | 08:32 |
| dcaliste | The ctag route makes this kind of changes useless. | 08:32 |
| chriadam | it 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 affect | 08:32 |
| chriadam | indeed | 08:33 |
| pvuorela | pong | 08:33 |
| chriadam | gmorning | 08:34 |
| dcaliste | Going 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 |
| dcaliste | Hello pvuorela. | 08:34 |
| pvuorela | dcaliste: 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 |
| dcaliste | If 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 |
| dcaliste | Grep for onAccountCreationError to see where the handle is. | 08:35 |
| dcaliste | It was in AccountCreationDialog.qml that has been removed (for reason of not being used). | 08:35 |
| dcaliste | So I'm afraid the error message is going no where. | 08:35 |
| dcaliste | I may be wrong though and is missing something. | 08:36 |
| dcaliste | chriadam, 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 |
| dcaliste | I 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 |
| pvuorela | dcaliste: quickly appearing it wasn't used before my removals either, right? | 08:38 |
| dcaliste | pvuorela, right. | 08:38 |
| dcaliste | Which brings me to MR#70 for CalDAV, to report such message to the user. | 08:39 |
| dcaliste | But I'm afraid there might be the same problem for the other account types. | 08:39 |
| chriadam | dcaliste: 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 |
| dcaliste | These 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 |
| dcaliste | chriadam: 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 |
| chriadam | tyvm much appreciated | 08:42 |
| pvuorela | dcaliste: 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 |
| chriadam | wondering if the error signal produces a translated string, or something which is more a developer error message | 08:44 |
| chriadam | if 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 |
| chriadam | but honestly don't remember, I will ask Bea about it tomorrow | 08:45 |
| dcaliste | It's translated strings, at least for CalDAV, see declarative/caldavaccountcalendarupdater.cpp#654 | 08:46 |
| chriadam | curious. so we should try to display those (below the "Oops" message or something perhaps | 08:47 |
| chriadam | thanks for raising it | 08:48 |
| chriadam | I will speak to Bea tomorrow and will discuss | 08:48 |
| dcaliste | chriadam, 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 |
| dcaliste | So the strings got lost at one point in the past, I guess. | 08:48 |
| chriadam | indeed :-( thanks | 08:49 |
| dcaliste | I let you both discuss with Bea about this. If you don't have time to handle this, I may help. | 08:49 |
| chriadam | was 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, sorry | 08:50 |
| dcaliste | chriadam, 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 |
| chriadam | cool. thanks very much as always for your contributions! | 08:51 |
| chriadam | have a great week, see you next Tuesday | 08:51 |
| dcaliste | Yep, have a pleasant evening. See you. | 08:52 |
| flypig | dcaliste, 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 Guest57279 | 08:55 | |
| flypig | dcaliste, thank you, I'd really appreciate it. Given it's your contribution, I'd like to have your thought. | 08:57 |
| flypig | *thoughts. | 08:57 |
| flypig | (one thought would be enough, but plural even better!) | 08:57 |
| dcaliste | Indeed ;) You should hear from myself tomorrow, I guess. | 08:59 |
| *** Guest57279 is now known as vilpan | 09:09 | |
| adantes | Hi | 09:44 |
| adantes | I guess I messed up badly with my sfos now | 09:44 |
| adantes | My wifi router is buging lately, and I was o transfer files to my phone via scp, but it said it couldnt access to port 22 | 09:45 |
| adantes | I went to developer mode, disabled and reanabled developer mode | 09:46 |
| adantes | it was takin forever to download developer pakages, so I quit the proccess, and rebooted wifi | 09:46 |
| adantes | Now, I can't enable developer mode. It says preparing changes and doesn't quit there | 09:47 |
| adantes | I really need to enable ssh access so I can access my files in the phone via wifi | 09:48 |
| adantes | SSH | 09:48 |
| adantes | Is there any tip you can give me? | 09:48 |
| adantes | Xperia XA2, SFOS X latest build | 09:48 |
| adantes | Xperia XA2 Ultra, SFOS X latest build | 09:48 |
| *** frinring_ is now known as frinring | 10:08 | |
| x2s | adantes: as stupid as it sounds, but did you try to reboot the phone already? | 10:25 |
| adantes | x2s: yes, of corse | 10:32 |
| adantes | I suppose something got corrupted | 10:33 |
| adantes | tried utilities, refresh package registry, etc. | 10:33 |
| x2s | then 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 anymore | 10:33 |
| adantes | no luck | 10:33 |
| adantes | just restored factory defaults | 10:34 |
| adantes | I needed a fresh start on it anyway | 10:34 |
| adantes | tnx anyway :+1: | 10:37 |
| x2s | having to do a factory reset is somehow sad :/ | 10:38 |
| spiiroin | adantes: 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 sfos | 10:49 |
| Herrie | mal: You around? | 12:28 |
| mal | Herrie: yes | 12:33 |
| Herrie | mal: 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 |
| mal | does strace show anything, assuming you can strace it? | 12:38 |
| mal | use 64-bit strace if needed | 12:39 |
| Herrie | Well I have logcat working | 12:39 |
| mal | ok | 12:39 |
| Herrie | And journalctl tells me it's starting hwservicemanager | 12:39 |
| Herrie | Lot of things in logcat tell me they're waiting for hwservicemanager.ready | 12:40 |
| mal | I would try to strace hwservicemanager to see what it is doing | 12:42 |
| Herrie | OK will give that a go | 12:43 |
| Herrie | Approach 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 |
| mal | wondering what wayland versions should we keep supporting in libhybris, not sure what versions the OSes using libhybris have | 12:47 |
| Herrie | On 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 |
| mal | in sfos we have latest wayland | 12:52 |
| mal | libhybris has some code that has same things implemented that are now in wayland | 12:53 |
| Herrie | mal: Best to check with Tofe at our end, he can tell you more for sure | 13:04 |
| mal | Herrie: https://github.com/mlehtima/libhybris-1/commit/e3be14f5961d2826ccf4420911db8aa5b05236d5 | 13:14 |
| adantes | spiiroin: no, I guess I didn't.. but when I upgraded to sfos 3.2 for the first time, it showed me an error msg | 13:19 |
| Herrie | mal: I'll check with Tofe and let you know | 13:20 |
| adantes | therefore, I was alsolooking for the need to put a fresh install | 13:20 |
| adantes | everythings cool now, except for the lack of the android store icon | 13:20 |
| adantes | :-P | 13:20 |
| adantes | that I'm still setuping the phone | 13:21 |
| Herrie | mal: Checked with Tofe seems that we don't use Wayland < 1.15 at our end | 14:19 |
| Herrie | We'd need to double check on actual targets, but we don't really see issues in your proposal | 14:20 |
| mal | Herrie: that was just to be backwards compatible, really I would want to remove the whole wayland-egl.c from libhybris | 14:33 |
| mal | Herrie: in case you want to see my whole cleanup branch https://github.com/mlehtima/libhybris-1/commits/cleanup still some small things to do | 14:35 |
| Herrie | mal: Any idea how I can use LD_PRELOAD for hwservicemanager and strace at the same time? | 14:38 |
| Herrie | If 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 directory | 14:39 |
| Herrie | Ah seems I can specify multiple .so's to LD_PRELOAD :) | 14:42 |
| mal | des the .so exist? | 14:46 |
| mal | ok | 14:47 |
| Herrie | mal: Yeah if I preload hwservicemanager seems to not crash, but then I cannot strace it from within my ADB ;) | 14:50 |
| Herrie | Without preloading the selinux stub it crashes. After preloading, it doesn't crash, but I cannot strace... So a bit catch 22 | 14:52 |
| Herrie | It complains that it cannot find libc++.so and a few others. Added all those and now strace will segfault ;) | 14:53 |
| mal | Herrie: are you using 64-bit strace? | 15:09 |
| Herrie | How do I know? Seems I only have 1 strace binary ;) | 15:10 |
| mal | not sure, I just have a separate one for 64-bit because sfos has only 32-bit strace | 15:11 |
| x2s | Herrie: do: file /usr/bin/strace | 15:14 |
| x2s | it will tell you | 15:14 |
| Herrie | Well on LuneOS side we don't have "file" command it seems | 15:19 |
| Herrie | But pretty sure it's 64 bits | 15:19 |
| x2s | do you have ldd? | 15:20 |
| x2s | then try that. It will tell you against which libs strace is linked. | 15:20 |
| Herrie | Nope also not | 15:22 |
| Herrie | But when I LD_Preloaded the 32 bits one it was complaining | 15:22 |
| Herrie | The 32 bits .so's from /lib folder | 15:22 |
| Herrie | When I did the 64 bits ones from lib64 it was not complaining, just segfaulting | 15:23 |
| x2s | What about strings /usr/bin/strace | head -n 1 ? | 15:24 |
| x2s | ;) | 15:24 |
| Herrie | Yup that works ;) /lib/ld-linux-aarch64.so.1 | 15:24 |
| Herrie | So 64 bits | 15:24 |
| Herrie | Ok 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 |
| mal | Herrie: well that would explain some things :D | 16:44 |
| Herrie | mal: Yeah, Halium relies on some of the .mk files in order to determine what to copy | 16:44 |
| Herrie | Sometimes these vendor ones are not complete (as in this case) | 16:45 |
| Herrie | I switched to a 3.18 kernel device from 3.4 based Hammerhead to avoid old kernel specific issues, but get these instead ;) | 16:46 |
| mal | Herrie: where did you get the newer kernel? | 16:55 |
| mal | or do you mean you changed to some other device completely? | 16:55 |
| mal | maybe I misunderstood that | 16:56 |
| Herrie | mal: Changed device completely | 16:58 |
| Herrie | Luckily with Halium it's not that much work most of the times ;) | 16:59 |
| mal | ok :) | 16:59 |
| Herrie | mal: 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 |
| Herrie | So I can test our 7.1 targets pretty easily with WIP 8.1 just sometimes there are issues in vendor & proprietary repos | 17:22 |
| Herrie | But 5.1 and 7.1 are old, so I'm working on 8.1 and 9.0 later. | 17:23 |
| Herrie | So we can support some newer targets | 17:23 |
| mal | Herrie: I should some day try to get sailfish running with halium, not sure if anyone did that | 17:25 |
| Herrie | mal: 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 wheel | 17:36 |
| Herrie | Mer/SFOS and LuneOS share most of kernel defconfig anyway | 17:37 |
| Herrie | UBPorts has some specifics for AppArmor, Plasma Mobile is pretty similar as well | 17:37 |
| Herrie | Normally we can take a Mer defconfig and use it 1:1 or with only a few minor changes | 17:37 |
| mal | Herrie: yes, probably doesn't need many changes in kernel side, sfos scripts probably need fixing | 17:39 |
| Mister_Magister | mal: or whoever https://git.merproject.org/mer-core/mce cert expired | 21:09 |
| mal | Mister_Magister: use git.sailfishos.org | 21:24 |
| Mister_Magister | mal: same thing | 21:24 |
| Mister_Magister | or not | 21:24 |
| Mister_Magister | whatever | 21:24 |
| mal | where do you build that? | 21:25 |
| Mister_Magister | shh | 21:25 |
| mal | for me git.sailfishos.org works fine | 21:25 |
| Mister_Magister | yea me too | 21:26 |
| Mister_Magister | but merproject.org is expired, is noone gonna do anything about it? | 21:26 |
| mal | well it was just noticed earlier this evening, maybe tomorrow when people are back at work | 21:28 |
| mal | but it's going being obsoleted anyway, it's just redirecting to git.sailfishos.org now | 21:29 |
| pketo | git.merproject.org cert updated, so redirects should work now, but what ever uses it should be pointed to git.sailfishos.org | 21:57 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!