Tuesday, 2021-04-06

*** zbenjamin_ is now known as zbenjamin01:38
*** frinring_ is now known as frinring01:50
*** jrt is now known as Guest8091502:44
*** ZucZero is now known as Zucca04:04
dcalisteHello chriadam, how are you ? Maybe I forgot to tell you that France moved to UTC+2 instead of UTC+1 one week ago for DST...06:59
chriadamhi dcaliste06:59
chriadamI'm well thanks06:59
chriadamFinland moved ahead an hour last week also, so I suspected that France would be similar07:00
chriadamI hope the surgeon was happy with your finger, during the examination last week?  no issues, I hope?07:00
dcalisteThanks, it's all clear. It was the last examination. She considered it recovered. I should mention that I agree !07:01
chriadamexcellent news!  if you have full movement back, she must have been a very good surgeon indeed, I guess.  that's excellent.07:02
chriadamon the QMF front: tonight, my plan is to rebase everything and get everything in, if possible07:03
dcalisteIndeed, I owe her a lot.07:03
chriadamI guess there might be some more changes which need to go on top of https://codereview.qt-project.org/c/qt-labs/messagingframework/+/337291 or is that still the "tip" currently?07:03
dcalisteAbout QMF, good plan ! Hopefully without too many going back and forth with the CI.07:03
dcalisteLet me check...07:04
chriadamwell, there will be some CI wrestling, I have no doubt.  but hopefully not too bad ;-)07:04
dcalisteFor the tip, yes, as far as I know it's this one.07:04
chriadam@flypig: can you check https://codereview.qt-project.org/c/qt-labs/messagingframework/+/31386707:05
chriadamI think that's the only one lacking codereview currently07:06
chriadamwell, the latest version I mean07:06
dcalisteYeh, and thanks a lot to flypig and yourself for the in-depth reviewing and contribution process.07:06
chriadamand huge thanks to you for your work in this area, definitely.  will be very nice when it finally integrates ;-)07:07
dcalisteNext big turmoil : moving away from dcop thingies in favor of QDBus... Well, maybe not tomorrow (or the month after!).07:07
chriadam... yes ;-)07:08
chriadambefore we get to the new PRs I saw (timezone shift things), I'd like to double check that I haven't missed anything from last weeks: aside from QMF things, are there any other outstanding PRs from before?07:10
chriadamI merged and tagged the PRs in caldav + buteo-syncfw last week -- thanks very much for those, sorry they both took so long.07:11
dcalisteThanks, no problem, no there is nothing still pending, just some new stuff.07:11
dcalisteAbout the CalDAV issue faced by one user, where I was blaming the lack of cooky passing two weeks ago, we have both him and myself continued to investigate and cookies are not the issue.07:11
chriadamthe issue only reproduces against his specific server, as far as I remember?07:13
dcalisteHis server is having issue with two consequent request, where the data of the first declined request is added to the HTTP stack, making the second one failing...07:13
dcalisteYes, it's very specific to his server.07:13
*** tosaraja_ is now known as tosaraja07:13
dcalisteStill under investigation, we've no idea what can cause this.07:14
chriadamwhen you say "added to the HTTP stack" do you mean "we on the client side send more data than the server is willing to accept" or do you mean "his server somehow accumulates the data for both requests when doing the second request handling"?07:14
dcalisteWell, that's not clear to me and it's stuck far inside Qt HTTP handling which is not easy for me to debug. I'm still thinking to a race condition server-side, but I'm surprised no one else is having the problem. The user is running a normal httpd server on OpenBSD.07:17
chriadamyeah, tricky.  Qt Network state machine could do pretty much anything in terms of resending data etc, using old buffer, etc... if it's HTTP rather than HTTPS you could use wireshark to determine whether the client is sending too much data, at least, I guess07:20
chriadambut if it is ... well ... I'm not sure how to resolve the issue aside from perhaps tearing down the QNetworkAccessManager and constructing a new one, before sending the second request07:20
chriadam(and maybe even that wouldn't work, depending on if QtNetwork uses some thread-local storage or something internally, not sure...)07:21
dcalisteYeh, well, that was more to tell you that cookies are not to be taken care of at least and his issue is quite local I think.07:21
dcalisteBut it drived me to propose https://git.sailfishos.org/mer-core/buteo-sync-plugin-caldav/merge_requests/79 for servers where the root is not part of the DAV server.07:22
dcalisteFor instance for Nextcloud server under a sudirectory.07:22
dcalisteIt's changing the first PROPFIND address not to poke the / of the server but the provided webdav path at server creation.07:23
dcalisteIt should not change much, beside finding the proper user principal for servers in a subdirectory.07:24
chriadamdefinitely we should be doing discovery from correct (i.e. dav) path, not necessarily server root07:24
chriadamI wonder if I made the same mistake in carddav?  I should double check.07:24
dcalisteIt's  not a big deal in CalDAV, because we have fallback mechanisms to reuse existing calendar paths, but I think it's cleaner like that.07:25
chriadamI agree, thanks.07:27
chriadamon mkcal side, Pekka has https://git.sailfishos.org/mer-core/mkcal/merge_requests/55 which resolves an issue which he saw after manually modifying his database.  I think it might not be possible "in practice" but probably good defensive validation in any case07:28
chriadamalso I have https://git.sailfishos.org/mer-core/mkcal/merge_requests/5607:29
dcalisteAbout mkcal!55, yes I discussed a bit there with pvuorela. I'm still wondering how it was possible to actually store incidences without a notebook id. But adding the validation check is good anyway.07:31
chriadamcool :-)  I still need to give it a review, but if you're happy with that one, and I don't see any issues, then we will merge and tag that one soon.07:32
dcalisteAbout mkcal!56, very nice catch indeed. I'm suprised that this memory leak was there since ages. And about the order of freeing, the solution you are proposing with pvuorela looks perfect.07:32
chriadamlucky pvuorela saw the format thing, at first I didn't think it was related at all07:33
chriadammy original solution was far less nice haha.07:33
chriadamI assume the base Calendar has a virtual dtor?  let me check07:34
chriadamoh, it's a QObject, so yes.07:35
chriadamwell, I will merge and tag mkcal 56 tomorrow then, thanks for taking a look.07:35
dcalisteFor information, still related to mkcal, Carl Schwan from KDE is working on a rewrie for Plasma of the calendar event handling, as far as I understand from his posts on this MR in upstream kcalendarcore : https://invent.kde.org/frameworks/kcalendarcore/-/merge_requests/2007:36
dcalisteHe's looking for a structure to store notebook-related data. So I mentioned mKCal::Notebook for reference.07:37
dcalisteIt's still WIP but he pushed last week this branch https://invent.kde.org/frameworks/kcalendarcore/-/commits/work/carl/plugin07:38
dcalisteDepending on the outcome, we may reuse part of these new objects from KCalendarCore and transfer part of the implementation currently in mKCal to KCalendarCore.07:38
chriadamyeah, I always wondered how KCalendarCore did anything without having something like mkcal Notebook07:39
dcalisteFrom the comment of the MR!20, it seems that it's done at the akonady level at the moment.07:40
chriadammy memory of Akonadi is pretty hazy, I haven't looked at it for a decade or something.  I thought it was a datastore abstraction?07:41
dcalisteYes, as far as I understand it. So it makes some sense also to have it there, we are doing it in our own SQlite backend code after all !07:42
dcalisteI'll continue to have an eye on this work and see if we can converge between Plasma and SailfishOS there to move the notebook handling out of the storage layer.07:42
chriadamindeed ;-)  yep, sounds good!07:42
chriadamthank you for taking the initiative on that07:42
chriadamI guess we have covered most of the "previous PRs" stuff, can continue to the new timezone shift PRs in nqpc/j-c ?07:43
chriadamI took a very quick look at those already, in general I agree that it's a super useful feature.07:43
dcalisteIt's something that I've wanted to implement for a long time now.07:44
chriadamI think that MartinS will have some design input, I will poke him07:44
dcalisteThat would be great. Thanks.07:44
chriadambtw typo in commit message: moth view -> month view07:44
dcalisteThe tricky stuff in my opinion is the calendar layout depending on the first day of week.07:46
dcalisteIn France we're chaning time in the Sunday night, early in the morning, and our first day of week is a Monday.07:46
dcalisteSo the night when we're changing time is inside a week line.07:47
dcalisteFor locale where the week-end is splitted between two lines, it requires a different design.07:47
dcalisteAnd some complication in the QML code as you may have seen.07:47
chriadamyes, definitely some tricky cases there07:48
chriadamhrm, pvuorela isn't on IRC today it seems07:49
chriadamhe and flypig have had more to do with jolla-calendar side than I have, recently.07:49
dcalisteI may add flypig as a reviewer for the jolla-calendar MR also, if it's not too demanding ?07:50
chriadamplease do ;-)07:51
chriadamcertainly, figuring out how best to indicate to the user that there is a DST transition, and what its shift-amount is, might take some time and thought.  the floating offset amount might not be intuitive enough, and also has some layout considerations as you mention07:52
dcalisteOk, done, thank you. I'm updating the commit message also to correct the typo.07:52
chriadamwas there anything else to discuss, today?  if not, I will start on rebasing those QMF PRs and pressing the stage button about 50 times :-P07:54
dcalisteYes, that's all, thank you. Good luck with the huge QMF upgrade.07:55
chriadamthank you.  I hope you have a great week!07:55
* chriadam -> away, gnight07:56
*** Herrie|2 is now known as Herrie15:55
ochernoHow do you find which variation of XA2 model one has: 3113 vs 3123?16:31
ThaodanTry gsmarena16:34
Thaodanbut I guess gsm bands16:34
pketoocherno: on android it should be in settings > system > about device, or something like that... assuming here that you are trying to figure out which sailfish image you need :)17:26
pketoor, the model is also on the label on the box, in case you have the original box17:30
attahor run "fastboot getvar product" on a computer, with the phone connected in fastboot mode17:35
ochernosorry was in meetings...18:20
ochernoI have this phone for lasy couple years, running SFOS18:21
ochernoIs there CLI command  that I can run on the phone to get the model ?18:23
pketoocherno: ssu s18:35
ochernothank you18:43
ochernoand.... it is h3113 ... thats why T-mo does not show love ... since my phone is missing their 4G freqs18:45
*** xenial-user is now known as Guest8395819:03
malocherno: what do you mean it's missing those?19:34
malocherno: if you want to see the actual device model (afaik that reported by ssu s is the codename used in the build) then maybe fastboot will tell that (fastboot getvar all)19:39
malocherno: in sony open devices all h31x3 devices use the same repos and android build, the actual hardware and factory firmware determines what 4g bands are supported19:43
ocherno4G bands: 1, 2, 4, 5, 7, 8, 12, 13, 17, 25, 28, 29, 66 - H312319:50
ocherno1, 2, 3, 5, 7, 8, 20, 38 - H311319:50
ochernoT-mo : 2, 5, 4, 12 ...19:51
malso which one is your hardware?19:54
malocherno: you know that for sure or checked via fastboot? ssu s won't tell the hardware variant20:07
ocherno'ssu s' did tell me H311320:17
malocherno: like I said, that says the image codename, not the hardware20:34
ochernowell ... then I did install this image 2-3 y ago when I knew the model20:38
malocherno: all h31x3 have the same image20:39

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