*** zbenjamin_ is now known as zbenjamin | 02:04 | |
*** frinring_ is now known as frinring | 03:02 | |
*** nyov is now known as Guest63652 | 04:02 | |
dcaliste | Hello chriadam, thank you for the different merges today. I've seen also that your Qt6 upgrade of QtPim has been validated, congrats ! | 07:58 |
---|---|---|
chriadam | hi dcaliste, yes I finally got those integrated haha | 07:59 |
chriadam | now I can start to upstream some of our changes | 07:59 |
chriadam | how has your week been? | 07:59 |
dcaliste | It was a long fight with the CI ;) | 07:59 |
chriadam | yes, it was haha | 07:59 |
dcaliste | Week was fine, thanks. Yesterday, I've seen this https://forum.sailfishos.org/t/calendar-bug-recurring-event-every-year-gets-treated-as-last-sunday-every-month/3316 and it's obviously misbehaving. | 08:00 |
dcaliste | Looking into it, I think it's an issue in Silica. | 08:01 |
dcaliste | Yesterday, I asked pvuorela for write access to submit a correcting MR, but he was busy I guess. | 08:01 |
chriadam | silica bug, interesting | 08:01 |
chriadam | I look forward to seeing the PR once pvuorela can sort out access | 08:02 |
dcaliste | I think the problem comes from the fact that in the dialog with the selection, only visible items are shown (good), but the index that is emitted is the index taking into account only the visible items, while everywhere else, like in the _updateCurrent method, the index are counted on the model items without taking into account the visibbility. | 08:03 |
chriadam | urgh | 08:03 |
dcaliste | The patch is simple : in the dialog, instead of emitting the index with the visibility, we should emit an index without the visibility. | 08:04 |
chriadam | makes sense | 08:04 |
dcaliste | The bug araises when you have enough items to show the selection dialog and when you have invisible items in the middle, and select items after the hidden ones. | 08:05 |
dcaliste | I don't think it's that common case. | 08:05 |
chriadam | yes, the ordering requirement makes it interesting | 08:06 |
dcaliste | About the CalDAV syncing issue that Bree noticed, do you have any info on reproducing it ? Is it linked to Nextcloud specifically ? | 08:07 |
chriadam | no info about how to reproduce the issue, yet, unfortunately. Bree was going to create a bug with the info, but haven't seen it yet. | 08:09 |
dcaliste | Ok, if it's linked specifically to Nextcloud, I need to find if there is a free trial service somewhere, it would help to solve the issue. | 08:10 |
dcaliste | It would be bad to miss the next release... | 08:10 |
chriadam | I use a docker image for nextcloud testing | 08:11 |
chriadam | I'll see if I can pastebin it, sec | 08:11 |
chriadam | I can't find my docker file currently | 08:16 |
chriadam | I'll have to get it when I'm back in the office tomorrow | 08:17 |
chriadam | sorry about that | 08:17 |
dcaliste | No problem, I'm totally ignorant about docker, but that would be good if I can start from your config. Thanks. | 08:18 |
dcaliste | Anyway, I need to learn about it so that's a good opportunity. I've already switched the SDK to docker base one, and I need to use it from time to time at work. | 08:19 |
chriadam | I really appreciate the help. the issue which Bree had was able to be reproduced with master, she said, so it wasn't a regression | 08:21 |
chriadam | hence why I merged that PR | 08:21 |
chriadam | so I'm not exactly sure what / how to repro it | 08:21 |
chriadam | but yeah, I will provide the docker file asap | 08:21 |
dcaliste | It seems to be linked to Nextcloud, because I cannot see it with OpenXchange. If I can reproduce it with a docker, that would be cool indeed. | 08:22 |
chriadam | in regards to your other outstanding PRs, are we down to just the sailfish-components-accounts one, and the jolla-calendar one, currently? oh, there's also the buteo-syncfw one that I was meant to merge a while ago | 08:23 |
chriadam | am I forgetting any? | 08:23 |
dcaliste | No, that's the state of affair indeed ! About the buteo-syncfw, it's the one adding extended log capabilities per item, right ? | 08:24 |
dcaliste | I think, I need to write the using code in CalDAV to see if the API is good enough and I didn't forget anything. | 08:25 |
chriadam | yes, it's that one. should I wait until you use it in the caldav plugin, just in case some other additions/changes are needed? | 08:25 |
dcaliste | Yes, I think we can delay it's integration up to the moment, the CalDAV part is ready. | 08:26 |
dcaliste | s/it's/its/ | 08:26 |
chriadam | probably for the best | 08:27 |
chriadam | I think flypig is going to take a deeper look at the setEnabled() s-c-a PR | 08:27 |
chriadam | aside from that, the jolla-calendar one is fine except for some strings, right? maybe we should just merge that one... flypig? | 08:27 |
dcaliste | Now that you merged the KCalCore bits, I'm going to publish also the changes in mKCal to inherit from MemoryCalendar and save a good amount of lines (even let say delegate maiuntenance to upstream KCalendar). | 08:27 |
dcaliste | I've seen the notes from flypig on the sailfish-account MR. I'm going to answer later today in the MR to keep track of the discussion. | 08:29 |
flypig | Yeah, I only just took a look at the setEnabled() changes this morning and I think I need to think more on it. Feel free to tell me I'm wrong on both points dcaliste. | 08:29 |
Kabouik | (Stupid question: is a SFOS meeting ongoing or just the channel is busy today?) | 08:29 |
chriadam | we meet with dcaliste at this time. other contributors are welcome to join in, also | 08:30 |
dcaliste | Looking quickly to your remarks, flypig, this morning before our meeting, I think I already checked on some while creating the MR, but I need to check again and answer properly, so later today I guess. | 08:30 |
Kabouik | Thanks! I can't right now, other meeting in real life right now, but I'll read later | 08:30 |
chriadam | (dcaliste is so prolific with his contributions that I wanted a regular session to ensure we stay on top of it all) | 08:30 |
chriadam | :-) | 08:31 |
flypig | dcaliste, there's no rush for your reply, I expected you'd likely thought about it already. | 08:31 |
flypig | For the jolla-calendar PR: I'd argue for merging it already, but it'd be good to have pvuorela's blessing. | 08:31 |
dcaliste | about the jolla-calendar MR, sure, no problem. | 08:32 |
pvuorela | dcaliste: what was that access thing? think i might have missed something. | 08:35 |
dcaliste | It's about https://forum.sailfishos.org/t/calendar-bug-recurring-event-every-year-gets-treated-as-last-sunday-every-month/3316, I think it's a silica bug and I prepared a MR for dicussion in silica but I have only READ access at the moment. | 08:36 |
dcaliste | I commented about it yesterday around noon on this channel, but you may be busy at that time pvuorela. | 08:37 |
pvuorela | dcaliste: ah, there. will handle. | 08:38 |
dcaliste | Thank you pvuorela ! | 08:38 |
chriadam | tyvm | 08:39 |
chriadam | was there anything else for us to cover this week? I haven't yet fully digested the kcalcore upgrade information, unfortunately, so I don't have any input on that yet, or where we can help. But I will have some availability / capacity free to help with that activity over the next couple of weeks. | 08:42 |
dcaliste | I think for the migration of kcalcore, you can compile my new repo https://git.sailfishos.org/dcaliste/kf5-calendarcore | 08:44 |
chriadam | oh wow, thanks | 08:44 |
dcaliste | Then, you can take EAS or buteo social and see what it is changing for it compiles. | 08:44 |
chriadam | yep | 08:44 |
chriadam | great | 08:45 |
chriadam | I will hopefully get a chance to take a look at that next week, then :-) | 08:45 |
dcaliste | See https://git.sailfishos.org/mer-core/mkcal/merge_requests/16/diffs for instqnce what needs to be changed in the .pro file to compile with the upstream version. | 08:46 |
dcaliste | It will give you an better idea on the changes it requires to at least compile. | 08:46 |
dcaliste | Testing and have it running is another story... | 08:46 |
dcaliste | Oh, I think the mKCal MR I'm pointing to is out of date, based on early tests for migration. | 08:47 |
dcaliste | I've a better one on disk, but still not quite perfect, I need to polish it more (and make all the tests pass). | 08:47 |
dcaliste | But it's a complicated matter, because many things changed between KDateTime and QDateTime that requires to rewrite the tests completely but trying to keep the general idea of them. | 08:48 |
chriadam | ouch, yeah | 08:50 |
chriadam | If there is some nice way to divide up the work into chunks, I can definitely take some of those chunks | 08:50 |
dcaliste | Thanks, well looking for other repos I'm not very accustomed to is a good help indeed. | 08:52 |
chriadam | :-) buteo-social / sailfish-eas sounds like a good place for me to start | 08:52 |
dcaliste | And doing a listing of all repo requiring KCalCore at the moment in their build requirements to check if we don't miss any is also a good help, because I cannot do that easily. | 08:53 |
chriadam | that's a very good point | 08:54 |
dcaliste | I know pvuorela often did some grepping in all repos for me previously, maybe it's something you can do easily also ? | 08:54 |
chriadam | yep, the grepping definitely | 08:55 |
chriadam | I can also ask mkosola if there's some fancy dependency graph tool available from the build side.. | 08:55 |
chriadam | but let's see | 08:55 |
chriadam | ok, well, if nothing else to discuss, maybe we shall adjourn until next week? | 08:56 |
chriadam | thanks again for your huge efforts and your patience with me being slow to review and merge! | 08:56 |
dcaliste | Yeh, my work for this week may be : | 08:56 |
dcaliste | - open the mKCal MR on ExtendedCalendar rework, | 08:57 |
dcaliste | - begin to implement per item logging now that the failure branch is in (it will reuse part of the mechanisms used for failure reporting), | 08:57 |
dcaliste | - push the silica MR for discussions, | 08:58 |
dcaliste | - try to improve the mKCal rebase on upstream (no promise). | 08:58 |
chriadam | thanks very much :-) | 08:58 |
dcaliste | - and also maybe try to setup a docker for Nextcloud testing. | 08:58 |
chriadam | I'll send you the docker file tomorrow | 08:59 |
chriadam | I will keep an eye out for the silica PR too :-) | 08:59 |
dcaliste | Thanks. | 08:59 |
chriadam | excellent :-) Have a fantastic week! | 08:59 |
chriadam | thanks also flypig and pvuorela | 08:59 |
* chriadam -> home, gnight | 08:59 | |
dcaliste | You too, thank you for the discussions and the reviews. | 08:59 |
chriadam | :-) | 08:59 |
flypig | Thanks guys, and thanks as always dcaliste :) | 09:01 |
dcaliste | flypig, if you have any questions on your Buteo social MR, don't hesitate to ping here or on Gitlab when you have time to come back to it. | 09:02 |
flypig | Ah, yes, thank you dcaliste. I'm about halfway through making the changes. I'll push an update (hopefully this week, but I've got sidetracked with other stuff). Your comments were super-helpful. Thank you. | 09:03 |
dcaliste | Looking at what you did, I wonder (or dream let say) if we could have a proper deserialisation absttraction on KCal::Incidences, because most of the sync-logic code looks very similar between CalDAV and Google one. | 09:05 |
dcaliste | Of course it's more smoke thinking than actual work to do, because there are many subtle variations I guess, but many issues are identical between the two and bugs also it seems. | 09:06 |
flypig | That would be nice :) It's hard to say whether there might be sync edge cases that differ between the two. | 09:06 |
flypig | It would be a thing of beauty though! | 09:06 |
flypig | It would also help to avoid duplicating fixes. Right now I'm really duplicating the fixes you already did for caldav. | 09:08 |
dcaliste | That's what I notice looking also looking at your MR, but there no easy way not to duplicate at the moment :/ I tried several times earlier to divide NotebookSyncAgent in CalDAV into several classes to separate sync-logic from actual storage / incidence peculiarities but with no success. Always ended up with a spageti-like code. | 09:12 |
dcaliste | But well, looking at the Google sync implementation, it may provide me some new ideas, we never know. | 09:13 |
pvuorela | dcaliste: adjusted silica branch permissions. | 09:42 |
dcaliste | Thank you pvuorela, it works. | 09:44 |
gmc | ugh, fell for it again.. qt 5.7 does not have endsWith on js strings ..... | 09:50 |
gmc | dcaliste: if you want, I can create an account for you on my nextcloud instance for testing | 09:51 |
dcaliste | gmc: that would be great indeed ! | 09:51 |
samsep10l | Hey people! Anyone know what does dsme mean? | 16:34 |
samsep10l | For what is it | 16:35 |
samsep10l | ? | 16:35 |
samsep10l | People do I need NFS support? Porting to Xiaomi Mi 8(dipper | 16:43 |
x2s | samsep10l: depends. Do you want to use NFS? | 17:14 |
samsep10l | x2s: No actually, I am asking because I am not sure if it is needed by system. | 17:51 |
samsep10l | I heard about NFS for the first time | 17:51 |
x2s | Just one of the oldest network filesystems: https://en.wikipedia.org/wiki/Network_File_System | 18:10 |
x2s | the system wont need it to run | 18:11 |
attah | Would anyone here in the fishyverse be interested in cellular protocol logging? | 18:53 |
fledermaus | attah: what level of detail? | 20:26 |
attah | fledermaus: RRC procedures | 20:27 |
fledermaus | attah: fascinating. I have no requirement for such but I'm always interested in drilling down into lower layers of stuff. | 20:32 |
fledermaus | does sfos expose that to userland? | 20:35 |
attah | more or less, as root you can persuade /dev/diag to give it out | 20:36 |
fledermaus | fun. | 20:41 |
attah | There are several tools that do this to slightly different extents... i hacked in some stuff to "QCSuper" to allow the program to work with a log forwarder you start manually on the phone (as opposed to having it started through adb) | 20:41 |
attah | https://github.com/attah/QCSuper/tree/tmp_dualsim | 20:41 |
attah | "This branch is 2 commits ahead of P1sec:master." | 20:41 |
attah | And i hacked in dualsim log format so my Xperia 10 produces something useful | 20:42 |
attah | The better solution is really https://github.com/fgsect/scat, but i haven't been arsed to convince it to work with straight /dev/diag | 20:43 |
attah | supposedly it is enough, and perhaps more useful, to get the usbmoded mode right... but wasn't able to do that either | 20:43 |
spiiroin | samsep10l: dsme = Device State Management Entity; orchestrates shutdown/reboot, keeps taps on temperatures, hw and sw watchdogs, aligned timers, ... | 20:56 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!