| *** zbenjamin_ is now known as zbenjamin | 01:38 | |
| *** frinring_ is now known as frinring | 01:50 | |
| *** jrt is now known as Guest80915 | 02:44 | |
| *** ZucZero is now known as Zucca | 04:04 | |
| dcaliste | Hello 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 |
|---|---|---|
| chriadam | hi dcaliste | 06:59 |
| chriadam | I'm well thanks | 06:59 |
| chriadam | Finland moved ahead an hour last week also, so I suspected that France would be similar | 07:00 |
| chriadam | I hope the surgeon was happy with your finger, during the examination last week? no issues, I hope? | 07:00 |
| dcaliste | Thanks, it's all clear. It was the last examination. She considered it recovered. I should mention that I agree ! | 07:01 |
| chriadam | excellent news! if you have full movement back, she must have been a very good surgeon indeed, I guess. that's excellent. | 07:02 |
| chriadam | on the QMF front: tonight, my plan is to rebase everything and get everything in, if possible | 07:03 |
| dcaliste | Indeed, I owe her a lot. | 07:03 |
| chriadam | I 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 |
| dcaliste | About QMF, good plan ! Hopefully without too many going back and forth with the CI. | 07:03 |
| dcaliste | Let me check... | 07:04 |
| chriadam | well, there will be some CI wrestling, I have no doubt. but hopefully not too bad ;-) | 07:04 |
| dcaliste | For the tip, yes, as far as I know it's this one. | 07:04 |
| chriadam | excellent. | 07:05 |
| chriadam | @flypig: can you check https://codereview.qt-project.org/c/qt-labs/messagingframework/+/313867 | 07:05 |
| chriadam | I think that's the only one lacking codereview currently | 07:06 |
| chriadam | well, the latest version I mean | 07:06 |
| dcaliste | Yeh, and thanks a lot to flypig and yourself for the in-depth reviewing and contribution process. | 07:06 |
| chriadam | and huge thanks to you for your work in this area, definitely. will be very nice when it finally integrates ;-) | 07:07 |
| dcaliste | Next 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 |
| chriadam | before 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 |
| chriadam | I merged and tagged the PRs in caldav + buteo-syncfw last week -- thanks very much for those, sorry they both took so long. | 07:11 |
| dcaliste | Thanks, no problem, no there is nothing still pending, just some new stuff. | 07:11 |
| dcaliste | About 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 |
| chriadam | the issue only reproduces against his specific server, as far as I remember? | 07:13 |
| dcaliste | His 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 |
| dcaliste | Yes, it's very specific to his server. | 07:13 |
| *** tosaraja_ is now known as tosaraja | 07:13 | |
| dcaliste | Still under investigation, we've no idea what can cause this. | 07:14 |
| chriadam | when 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 |
| dcaliste | Well, 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 |
| chriadam | yeah, 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 guess | 07:20 |
| chriadam | but 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 request | 07: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 |
| dcaliste | Yeh, 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 |
| dcaliste | But 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 |
| dcaliste | For instance for Nextcloud server under a sudirectory. | 07:22 |
| dcaliste | It's changing the first PROPFIND address not to poke the / of the server but the provided webdav path at server creation. | 07:23 |
| dcaliste | It should not change much, beside finding the proper user principal for servers in a subdirectory. | 07:24 |
| chriadam | definitely we should be doing discovery from correct (i.e. dav) path, not necessarily server root | 07:24 |
| chriadam | I wonder if I made the same mistake in carddav? I should double check. | 07:24 |
| dcaliste | It'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 |
| chriadam | I agree, thanks. | 07:27 |
| chriadam | on 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 case | 07:28 |
| chriadam | also I have https://git.sailfishos.org/mer-core/mkcal/merge_requests/56 | 07:29 |
| dcaliste | About 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 |
| chriadam | cool :-) 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 |
| dcaliste | About 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 |
| chriadam | lucky pvuorela saw the format thing, at first I didn't think it was related at all | 07:33 |
| chriadam | my original solution was far less nice haha. | 07:33 |
| chriadam | I assume the base Calendar has a virtual dtor? let me check | 07:34 |
| chriadam | oh, it's a QObject, so yes. | 07:35 |
| chriadam | well, I will merge and tag mkcal 56 tomorrow then, thanks for taking a look. | 07:35 |
| dcaliste | For 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/20 | 07:36 |
| dcaliste | He's looking for a structure to store notebook-related data. So I mentioned mKCal::Notebook for reference. | 07:37 |
| dcaliste | It's still WIP but he pushed last week this branch https://invent.kde.org/frameworks/kcalendarcore/-/commits/work/carl/plugin | 07:38 |
| dcaliste | Depending 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 |
| chriadam | yeah, I always wondered how KCalendarCore did anything without having something like mkcal Notebook | 07:39 |
| dcaliste | From the comment of the MR!20, it seems that it's done at the akonady level at the moment. | 07:40 |
| chriadam | my 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 |
| dcaliste | Yes, 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 |
| dcaliste | I'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 |
| chriadam | indeed ;-) yep, sounds good! | 07:42 |
| chriadam | thank you for taking the initiative on that | 07:42 |
| chriadam | I guess we have covered most of the "previous PRs" stuff, can continue to the new timezone shift PRs in nqpc/j-c ? | 07:43 |
| dcaliste | Yes. | 07:43 |
| chriadam | I took a very quick look at those already, in general I agree that it's a super useful feature. | 07:43 |
| dcaliste | It's something that I've wanted to implement for a long time now. | 07:44 |
| chriadam | I think that MartinS will have some design input, I will poke him | 07:44 |
| dcaliste | That would be great. Thanks. | 07:44 |
| chriadam | btw typo in commit message: moth view -> month view | 07:44 |
| dcaliste | The tricky stuff in my opinion is the calendar layout depending on the first day of week. | 07:46 |
| dcaliste | In France we're chaning time in the Sunday night, early in the morning, and our first day of week is a Monday. | 07:46 |
| dcaliste | So the night when we're changing time is inside a week line. | 07:47 |
| dcaliste | For locale where the week-end is splitted between two lines, it requires a different design. | 07:47 |
| dcaliste | And some complication in the QML code as you may have seen. | 07:47 |
| chriadam | yes, definitely some tricky cases there | 07:48 |
| chriadam | hrm, pvuorela isn't on IRC today it seems | 07:49 |
| chriadam | he and flypig have had more to do with jolla-calendar side than I have, recently. | 07:49 |
| dcaliste | I may add flypig as a reviewer for the jolla-calendar MR also, if it's not too demanding ? | 07:50 |
| chriadam | please do ;-) | 07:51 |
| chriadam | certainly, 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 mention | 07:52 |
| dcaliste | Ok, done, thank you. I'm updating the commit message also to correct the typo. | 07:52 |
| chriadam | tyvm | 07:52 |
| chriadam | was there anything else to discuss, today? if not, I will start on rebasing those QMF PRs and pressing the stage button about 50 times :-P | 07:54 |
| dcaliste | Yes, that's all, thank you. Good luck with the huge QMF upgrade. | 07:55 |
| chriadam | thank you. I hope you have a great week! | 07:55 |
| * chriadam -> away, gnight | 07:56 | |
| *** Herrie|2 is now known as Herrie | 15:55 | |
| ocherno | How do you find which variation of XA2 model one has: 3113 vs 3123? | 16:31 |
| Thaodan | Try gsmarena | 16:34 |
| Thaodan | but I guess gsm bands | 16:34 |
| pketo | ocherno: 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 |
| pketo | or, the model is also on the label on the box, in case you have the original box | 17:30 |
| attah | or run "fastboot getvar product" on a computer, with the phone connected in fastboot mode | 17:35 |
| ocherno | sorry was in meetings... | 18:20 |
| ocherno | I have this phone for lasy couple years, running SFOS | 18:21 |
| ocherno | Is there CLI command that I can run on the phone to get the model ? | 18:23 |
| pketo | ocherno: ssu s | 18:35 |
| ocherno | thank you | 18:43 |
| ocherno | and.... it is h3113 ... thats why T-mo does not show love ... since my phone is missing their 4G freqs | 18:45 |
| *** xenial-user is now known as Guest83958 | 19:03 | |
| mal | ocherno: what do you mean it's missing those? | 19:34 |
| mal | ocherno: 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 |
| mal | ocherno: 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 supported | 19:43 |
| ocherno | 4G bands: 1, 2, 4, 5, 7, 8, 12, 13, 17, 25, 28, 29, 66 - H3123 | 19:50 |
| ocherno | 1, 2, 3, 5, 7, 8, 20, 38 - H3113 | 19:50 |
| ocherno | T-mo : 2, 5, 4, 12 ... | 19:51 |
| mal | so which one is your hardware? | 19:54 |
| ocherno | H3113 | 19:55 |
| mal | ocherno: you know that for sure or checked via fastboot? ssu s won't tell the hardware variant | 20:07 |
| ocherno | 'ssu s' did tell me H3113 | 20:17 |
| mal | ocherno: like I said, that says the image codename, not the hardware | 20:34 |
| ocherno | well ... then I did install this image 2-3 y ago when I knew the model | 20:38 |
| mal | ocherno: all h31x3 have the same image | 20:39 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!