| *** frinring_ is now known as frinring | 01:32 | |
| *** zbenjamin_ is now known as zbenjamin | 02:13 | |
| sauron | Hello. Is there a command to turn USB changing on? | 04:37 |
|---|---|---|
| sauron | File /sys/class/power_supply/usb/health contains "Unspecified failure" | 04:59 |
| dcaliste | Hello chriadam, happy new year. | 08:03 |
| chriadam | hello dcaliste, happy new year to you also! | 08:03 |
| chriadam | I hope that you had a nice christmas / new year break | 08:03 |
| dcaliste | Yes, thank you, everything was fine. I wish the same apply to you and your family. | 08:04 |
| chriadam | yep, wasn't too bad | 08:05 |
| chriadam | just wishing that covid would magically vanish haha | 08:05 |
| chriadam | I still haven't caught up on all of the latest PRs unfortunately | 08:06 |
| chriadam | but let's start with the jolla-calendar side | 08:07 |
| chriadam | flypig said that https://bitbucket.org/jolla/ui-jolla-calendar/pull-requests/266 should be good to merge/tag but it needs to be rebased first | 08:07 |
| chriadam | also, he was wondering if https://bitbucket.org/jolla/ui-jolla-calendar/pull-requests/267 should be declined? | 08:07 |
| dcaliste | For 267, yes, we can decline it, waiting for better solution. | 08:09 |
| dcaliste | I'm looking at rebasing 266. | 08:10 |
| chriadam | ty | 08:11 |
| chriadam | thanks also for reminding me of the semantics of the webcal notebooks in my "local event purge on delete" PR | 08:11 |
| dcaliste | Ok, done. I've force pushed the rebased version of 266. | 08:12 |
| chriadam | cheers! | 08:12 |
| dcaliste | No problem for webcal things. I was wondering where to put the purge for local events. Where you are proposing is a good idea. | 08:12 |
| dcaliste | I've also declined 267 writing the reason for it. | 08:14 |
| dcaliste | While we are at jolla-calendar, I've reworked 276 to follow the design proposed by Martin. | 08:15 |
| chriadam | oh, let me check that one | 08:15 |
| chriadam | great, thanks - I have asked Pekka if he can show Martin the result on device | 08:17 |
| chriadam | I will test/review later this week also unless Pekka does that first. | 08:18 |
| dcaliste | Great, thanks all of you. | 08:18 |
| dcaliste | About middleware, I've upstreamed the patch from blam for KCalendarCore in the case of deleting recurring events with exceptions. | 08:19 |
| dcaliste | I've spotted another delete issue there doing it. Here is the MR for SailfishOS : https://git.sailfishos.org/mer-core/kf5-calendarcore/merge_requests/2 | 08:20 |
| dcaliste | blam approved it recently. | 08:20 |
| dcaliste | And since it has been upstreamed already, it's just updating some Qt version patch and move on the submodule to latest. | 08:21 |
| chriadam | cool, looks like it needs a bug reference, let me find an appropriate one | 08:21 |
| chriadam | JB#52656 is probably fine | 08:24 |
| dcaliste | Ok, I'm adding it. | 08:24 |
| chriadam | thanks | 08:25 |
| chriadam | is that one ready for merge/tag now? | 08:25 |
| dcaliste | Yes, I've added the bug tag in commit message also. I guess it's fine to go in. | 08:27 |
| chriadam | tyvm for handling the upstreaming | 08:27 |
| chriadam | greatly appreciated. I will do a final smoke test / build tomorrow, then merge and tag. | 08:28 |
| dcaliste | Ok, nice thank you. | 08:29 |
| dcaliste | Coming with new KCalendarCore, we need to adjust a bit mKCal to save some properties that have been added in-between, see https://git.sailfishos.org/mer-core/mkcal/merge_requests/50 | 08:30 |
| dcaliste | The URL case is straight forwrad in my opinion. | 08:30 |
| dcaliste | Because saving the URI there was a mistake in my opinion, since it was not reread. | 08:31 |
| dcaliste | Saving something that was not read is useless, so we can easily save the URL instead now that incidences have API for it. | 08:31 |
| dcaliste | (URI was just a rewrite of the UID with a scheme). | 08:32 |
| dcaliste | The second commit in this MR, saving event colour, is more debatable. | 08:32 |
| dcaliste | I chose the easy route using an existing extra field, instead of altering the table itself. | 08:32 |
| dcaliste | What do you think ? | 08:32 |
| chriadam | I personally am fine with making use of the existing field if it exists... pvuorela do you agree? | 08:33 |
| chriadam | regarding the other one ... can you explain a bit more what you mean when you say "it was not reread" ? | 08:33 |
| chriadam | for the URI I mean | 08:33 |
| chriadam | do you mean: that line which is commented out originally, 1356? | 08:34 |
| dcaliste | If you look at the selectComponent(), yes the line was commented. And it was commented, because there is no API to set the URI, obviously. | 08:34 |
| dcaliste | Because it is a read property, built around the UID itself. | 08:35 |
| dcaliste | I mean no API in KCalendarCore::Incidence. | 08:35 |
| chriadam | aha | 08:36 |
| chriadam | so this doesn't change the semantics of anything, except that it will now store (to that db field) whatever the client sets in setUrl() ? | 08:36 |
| dcaliste | Exact. | 08:37 |
| chriadam | but it doesn't change the semantics of the existing uri() method, I mean | 08:37 |
| dcaliste | Exact also. | 08:37 |
| chriadam | great | 08:37 |
| pvuorela | yea, think the empty properties were supposed to be used for new additions. | 08:37 |
| pvuorela | though suppose locally there's no much need for event colors. | 08:38 |
| dcaliste | pvuorela, locally, no, but for synced event, like that the colour is not lost when sending back a modification to the server. | 08:38 |
| dcaliste | At the moment, any modification to a synced event will reset its colour. If on another device you have the colour, that's not very nice ! | 08:39 |
| chriadam | very true. also if we have the data, we might use it in future in our calendar app also, who knows. | 08:40 |
| dcaliste | colour per event was missing in KCalCore, but I added it some weeks ago upstream because libical read it since its version 3. | 08:41 |
| chriadam | :-) | 08:42 |
| dcaliste | Saving it in mKCal would allow to at least keep it even if we don't use it at the moment in SailfishOS. | 08:42 |
| dcaliste | I'm not fan myself of having per event colour, but some users requested it. | 08:42 |
| chriadam | yep, definitely better to do that, than to clobber user data during round trip sync | 08:42 |
| dcaliste | I may find some old TJC thread on this. | 08:42 |
| chriadam | unrelated, but while I remember: where are we at with qt6 qmf upstream things? | 08:43 |
| chriadam | is there something you need me to do, on that side? | 08:43 |
| dcaliste | Oh yes ;) I've divided the transition into logical commits but there are many and they need review... | 08:44 |
| chriadam | great | 08:46 |
| chriadam | I will get started on that sometime this week, I hope | 08:47 |
| dcaliste | That would be great, thanks. | 08:47 |
| chriadam | maybe flypig or pvuorela could help with that also? flypig do you have an upstream Qt account for review etc? | 08:47 |
| dcaliste | Sorry to be back with mkcal, but there is this somehow old MR : https://git.sailfishos.org/mer-core/mkcal/merge_requests/48, where flypig commented about a possible bug with recreated events. I tried to address this issue in https://git.sailfishos.org/mer-core/mkcal/merge_requests/51 | 08:50 |
| dcaliste | I've rebased the latter on latest master. | 08:50 |
| flypig | chriadam: sorry, catching up on the conversation. Yes, I have a Qt account and am happy to help if I can. I'll need to catch up. | 08:51 |
| dcaliste | About the former, I'm discussing the issue in detail in the MR overview, with possible solutions and their drawbacks. | 08:51 |
| dcaliste | Hello flypig, happy new year and thank you for the help. | 08:51 |
| dcaliste | In the Qt6 transition for QMF, most of the changes are staright forward, but I made the mistake to take the occasion to move from QregExp to QRegularExpression instead of using the compat package for it also. | 08:52 |
| flypig | Happy new year to you too :) Thank you for all your effort and contributions. | 08:52 |
| dcaliste | So there are some extensive changes regarding the regexp and even if I tried to be very cautious I may have introduced bugs there :( | 08:53 |
| chriadam | if the unit tests pass everything must be fine :-P | 08:54 |
| chriadam | regarding those mkcal PRs: I'm a bit nervous about changing the semantics of fetch deleted incidences method, as that could affect sync potentially | 08:54 |
| chriadam | but I haven't checked the PR in detail, yet, unfortunately | 08:55 |
| chriadam | the solution in MR#51 seems sensible to me | 08:55 |
| dcaliste | MR #48 won't change existing behaviour. It just give the additional possibility to get all deleted events, not just those deleted after a date AND created before this date. | 08:59 |
| chriadam | ah, great. | 09:00 |
| dcaliste | About MR #51, it's independant and try to fix an already existing issue, just that this issue was raised by flypig during the discussion of MR #48 | 09:00 |
| chriadam | yep | 09:00 |
| dcaliste | We can discuss these in lengther details next week. | 09:01 |
| chriadam | sounds good to me, thanks. | 09:01 |
| dcaliste | If you still have time, there is a last point I would like to address in jolla-settings. | 09:01 |
| chriadam | were there any other open MRs which need my attention? | 09:01 |
| chriadam | yep | 09:01 |
| chriadam | definitely | 09:01 |
| dcaliste | Its related to https://forum.sailfishos.org/t/kolab-now-and-sfos-3-4/4106 | 09:01 |
| dcaliste | and https://forum.sailfishos.org/t/unable-to-sync-fastmail-calendars-after-3-4-0-24-upgrade | 09:02 |
| dcaliste | Since 3.4.0 changes in account creation, I think the login / password are checked on the root of the server before going further and retrieving calendar list... | 09:03 |
| dcaliste | On some servers, the authentication on root is forbidden. | 09:03 |
| dcaliste | So account creation is failing. | 09:03 |
| dcaliste | Restoration from storage is failing also for the same reason I guess. | 09:04 |
| chriadam | eek. | 09:04 |
| chriadam | so we need to fallback to trying on ... either caldav calendars path, or carddav addressbooks path, or webdav home set path? | 09:05 |
| dcaliste | Yes, that was my first guess, but there is an issue doing so : the caldav path may be guessed. | 09:06 |
| dcaliste | So not available at that point. | 09:06 |
| chriadam | what do you mean by "guessed"? do you mean, looked up via the .well-known endpoint, or something else? | 09:06 |
| dcaliste | See the kolab issue, there is no webdav path, and caldav and carddav paths are different. | 09:07 |
| dcaliste | Yes, looked up via .well-known. | 09:07 |
| dcaliste | (well in the kolab report the .well-known seems to fail but that's another story, more related to server side I think). | 09:08 |
| dcaliste | So the situation is : | 09:09 |
| dcaliste | - server root / webdavpath may be forbidden and refused for authentication. | 09:09 |
| dcaliste | - server root/ webdav path/.well-known may be the solution to try to authenticate | 09:10 |
| dcaliste | - using the caldav path or the carddav one may not be possible, because not provided by the user at that point. | 09:10 |
| chriadam | thanks. I've created JB#52704 for this, and will poke Bea to investigate further | 09:11 |
| dcaliste | Thank you, the solution is not easy in my opinion and relies a lot on server implementation, difficult to find a universal solution. But thanks. I'll keep an eye on the repo and will comment if I can give constructive opinion. | 09:12 |
| chriadam | yeah, trying to support all different possible servers is ... hard ;-) but we'll do the best we can. thanks very much for bringing it to my attention | 09:13 |
| dcaliste | No problem, the workaround to create separated accounts puting the *DAV path in the webDAV path to cheat the code highlight the issue but is a bit ugly... | 09:14 |
| chriadam | yeah definitely shouldn't be required. | 09:14 |
| chriadam | was there anything else for us to discuss today? or, anything I missed in this quick summary: | 09:15 |
| chriadam | 1) flypig to merge/tag jolla-calendar PR#266 | 09:15 |
| chriadam | 2) pvuorela to show mschuele jolla-calendar PR#276, and pvuorela and chriadam to review | 09:15 |
| chriadam | 3) kf5-calendarcore MR#2 to be merged/tagged tomorrow after I do a quick smoke test build | 09:16 |
| chriadam | 4) 3 outstanding mkcal MRs: MR#50, MR#48, MR#51 -> all ready for review. MR#50 LGTM, but would like flypig to check also. latter two might need more discussion next week. | 09:16 |
| chriadam | 5) qmf upstream PRs need review - chriadam to begin that review this week if possible | 09:17 |
| chriadam | 6) caldav/carddav account creation bug, JB#52704 blam to investigate | 09:17 |
| chriadam | . | 09:17 |
| dcaliste | That's it ! Thanks a lot. | 09:18 |
| chriadam | thank you very much | 09:19 |
| chriadam | have a great week! | 09:19 |
| * chriadam -> home, gnight | 09:19 | |
| *** albertux1 is now known as albertux | 10:17 | |
| piggz | rinigus: im now packaged for plasma-mobile! https://gitlab.manjaro.org/manjaro-arm/packages/community/plasma-mobile/amazfish/-/tree/master | 10:57 |
| rinigus | piggz: way to go! | 12:33 |
| piggz | rinigus: waiting on puremaps to be packaged to satisfy the mapbox requirements | 12:35 |
| rinigus | piggz: in manjaro? let's see if they will do it. it is packaged in pmOS and available as flatpak. but the latter doesn't help you in manjaro... as for mapbox requirement, having 2 apps using it already makes better case for them to work on it | 12:40 |
| piggz | rinigus: yup, he already told me it will get packaged with puremaps .... atleast it was relatively easy to package, no issues with services like i will get with click/flatpak | 12:41 |
| rinigus | piggz : so do they plan to package pure maps as well? | 17:03 |
| piggz | rinigus: i think so yes | 17:03 |
| piggz | ill be forcing it by requiring it for the pinetime navigation | 17:04 |
| piggz | :D | 17:04 |
| *** andy is now known as Guest19291 | 17:34 | |
| rinigus | piggz :) | 17:36 |
| *** andy is now known as Guest63568 | 18:13 | |
| Joel37 | question has been probably asked a million time but what phones sailfish works on any newer xperia | 18:51 |
| vilpan | Joel37: 10, 10 Plus, XA2 and X according to https://jolla.com/sailfishx/ | 20:13 |
| Joel37 | how can i get my providor (AT&T) to connect to my device? | 20:49 |
| piggz | rinigus: https://video.codingfield.com/videos/watch/30731b21-ca25-4f67-9680-098104fd7314 | 20:52 |
| rinigus | piggz: should be nice for cycling :) | 20:55 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!