| PsychoGame | I've got a question about the Ofono package used in Sailfish. Why does Sailfish use quite outdated Ofono release? Is this for compatibility reasons? I know that the Ofono in Sailfish has some SFOS specific patchsets on top of it, but isn't it beneficial to keep a littlebit track of upstream commits? If it is related to lack of time/manpower I'm willing to step in to cherry-pick upstream commits over to Sailfish Ofono. | 00:13 |
|---|---|---|
| dcaliste | Good evening chriadam ! | 06:57 |
| chriadam | hi dcaliste | 06:57 |
| chriadam | how has your week been? | 06:58 |
| dcaliste | Could have been better, anyway. I hope yours was good. | 06:58 |
| chriadam | Mine was ok, thanks. I hope that nothing too bad happened! | 06:59 |
| dcaliste | Oh, all right let say. Thanks for merging the account deletion fix. Do you think it could go as a hot fix before public 4.2.0 release ? | 07:00 |
| chriadam | I don't think so - 4.2.0 is basically frozen now | 07:00 |
| dcaliste | Because, when you delete an account, the account is deleted but the data stays. For all account types ! | 07:00 |
| dcaliste | It means that users will have no mean to delete such data later on. | 07:01 |
| chriadam | but I will poke Jorma and pvuorela about it.. | 07:01 |
| pvuorela | yea, bad but 4.2.0 is alreayd pretty far :/ | 07:02 |
| dcaliste | Well, one can still properly delete associated data once Buteo fix is shipped, but from CLI with a DBus call, which is not very easy to do for anyone. | 07:02 |
| dcaliste | Something like "dbus-send --session --type=method_call --print-reply --dest=com.meego.msyncd /synchronizer com.meego.msyncd.removeProfile string:'caldav-sync-295'" if you know the associated profile name... | 07:03 |
| thilo[m] | I noticed, that podqast is using 4-500mb ram. Its using pyotherside internaly. I found no good way so far to see how much ram is used by the qml and by the python side. Any ideas? | 07:05 |
| chriadam | smaps / smem maybe | 07:07 |
| dcaliste | I let you decide with Jorma of course, I understand that 4.2.0 is already quite far in the release process. | 07:07 |
| thilo[m] | Smem seems to list the biggest chunck as anonymous | 07:07 |
| thilo[m] | Smap, didnt know it, will take a look | 07:08 |
| chriadam | not sure if it still works, but QV4_MM_STATS=1 might tell you how much is used by the JS engine | 07:08 |
| chriadam | dcaliste: poked Jorma, he's considering the situation. thanks very much for raising it. | 07:10 |
| chriadam | I also saw https://github.com/sailfishos/kf5-calendarcore/pull/3 but didn't have a chance to review that one yet | 07:11 |
| dcaliste | Great thank you. | 07:11 |
| pvuorela | chriadam: merged :) | 07:11 |
| dcaliste | Yes the kcalendarcore is a follow up of the last community letter where a user was raising the lack of support for PERIOD definition of RDATE. | 07:11 |
| chriadam | oh, thanks! | 07:11 |
| dcaliste | Cool, thank you pvuorela. | 07:12 |
| chriadam | fyi, flypig is also back from vacation now | 07:13 |
| dcaliste | pvuorela, in the Qt5.6 compatibility patch I needed to add different new things linked to the extra_cmake_modules requiring now something above 5.80. | 07:13 |
| flypig | Physically yes. Mentally still getting there. | 07:13 |
| dcaliste | Would you welcome a bump of ecm in sailfishos ? I can prepare a PR to latest version ? | 07:14 |
| dcaliste | hello flypig, I hope you had fine weather and enjoyed your vacations. | 07:14 |
| dcaliste | About the PERIOD stuff, it's not the complete end of the story, because we need support inside mKCal. | 07:15 |
| flypig | dcaliste: thanks, it was very relaxing and enjoyable. I noticed you've had a busy couple of weeks; thanks for picking up the PERIOD changes. | 07:15 |
| dcaliste | Basically a PERIOD is a RDATE with a duration or an end date time. | 07:15 |
| chriadam | is extra_cmake_modules something kcalendarcore specific, or more broad? if it's more broad, ViGe might have some thoughts about the extra_cmake_modules thing | 07:15 |
| dcaliste | It's used by other packages also in SailfishOS, like karchive for instance. | 07:16 |
| dcaliste | Anything KDE related is using it actually. | 07:16 |
| dcaliste | As far as I know, one can bump ecm without bumping dependant packages, it's supposed to be backward compatible. | 07:16 |
| chriadam | great, well, PR would be welcome I assume, thanks. if it does affect some other things, I think sdk team might want to look at the PR a bit closely | 07:18 |
| dcaliste | Ok, I will give a try. It's not mandatory, since I revert missing bits in the patch in kcalendarcore, but having it would reduce the patch size and increase its maintainability. | 07:19 |
| chriadam | sounds good. thanks very much | 07:19 |
| dcaliste | About mKCal implementation for PERIOD, the current rdate table is containing an id to the component it belongs to, a type field (string to store rdate or exdate) and three field to store the {r,ex}date date time value (the timezone, and to integers depending we're using the time zone or not). | 07:20 |
| dcaliste | So I see three ways to implement it: | 07:20 |
| dcaliste | - the ugly, adding a new type like "rdateend", we can store the associated end date time, and another "rdateduration" we can store the duration in one of the integer field for date time. But we need to also store the rowid of the associated start rdate. So here comes the ugly : one can put it in the type like "rdateend-XX" and parse the type. | 07:23 |
| dcaliste | - the (not so) bad, expand the rdate table by adding four more columns (one for a duration and three for a end date time) and using new types like "rdateend" and "rdateduration". | 07:24 |
| dcaliste | - the (not so) good, wait for a complete rewriting of the database. | 07:24 |
| dcaliste | pvuorela, or chriadam, what do you think ? | 07:24 |
| chriadam | the "expand the table" option seems sane, and pvuorela's upcoming patch to allow database schema migration should allow something like that fairly simply, I hope? | 07:27 |
| pvuorela | need to catch up with the problem in more detail, but generally would like to have data stored properly. maybe related i started that schema migration thing last week but then needed to switch to other things. | 07:27 |
| pvuorela | btw calendarcore update caused some build failures :/ | 07:27 |
| dcaliste | Arf, sorry, it built fine in SDK… | 07:28 |
| pvuorela | itself it built fine but the depending projects fail | 07:28 |
| pvuorela | buteo plugins etc | 07:28 |
| pvuorela | /usr/include/KF5/KCalendarCore/kcalendarcore/calendar.h:46:10: fatal error: QIcon: No such file or directory | 07:28 |
| dcaliste | Ah I see. I didn't try to recompile depending projects over it :/ | 07:29 |
| dcaliste | Maybe an issue with the pkgconfig... kcalendarcore is using qicon in its public headers, so a -I for qtgui is needed. I guess it may be missing from the pkgconfig for some reason… | 07:30 |
| pvuorela | smells like something like that. | 07:31 |
| dcaliste | In the target declartion in the CMakeLists, the Qt5::Gui is declared public, let see if it's indeed put in the pkgconfig... | 07:32 |
| pvuorela | having gui dependency on calendar class feels suspicious to begin with. | 07:32 |
| dcaliste | They added it recently to associate an icon to the calendar... | 07:32 |
| dcaliste | If we don't like it, we can patch to remove these setIcon() and icon() methods from the Calendar class, we're not using them. | 07:33 |
| pvuorela | that's one way to solve the build failure | 07:34 |
| pvuorela | though suppose the pkgconfig would need to be fixed upstream too if they want to have this dependency | 07:35 |
| chriadam | yeah. on the one hand, forcing sync plugins etc to link against QtGui is kind of silly. but on the other hand, it's read only shared data so not too much of a concern. | 07:36 |
| dcaliste | Yes, line 123 in CMakeLists.txt, the DEPS in the pkgconfig declaration is only Qt5Core, Qt5Gui is missing. | 07:36 |
| chriadam | in short, I think I'd be happier with the "upstream PR to add dep" solution, even though I think the dependency isn't necessarily a good thing, overall the cost isn't too high. pvuorela do you agree? | 07:39 |
| pvuorela | yea. | 07:40 |
| dcaliste | As far as I remember, Qt5Gui was already used internally, but not public, but I cannot remember why... | 07:40 |
| dcaliste | See commit 6608e7c804 upstream introducing the Qt5Gui dependancy long time before the use of QIcon. | 07:42 |
| chriadam | indeed | 07:47 |
| chriadam | adding dep sounds fine, then ;-) | 07:47 |
| chriadam | did you have anything else to discuss today? | 07:47 |
| dcaliste | Here is the upstream MR : https://invent.kde.org/frameworks/kcalendarcore/-/merge_requests/55 | 07:48 |
| chriadam | tyvm | 07:48 |
| dcaliste | pvuorela, do you prefer to wait for upstream inclusion or do you prefer a quick patch in sailfishos package ? | 07:48 |
| dcaliste | I've tested that with this, mkcal is building fine in SDK. | 07:48 |
| pvuorela | dcaliste: i'd prefer now something quick as we have build failures. for that one was pondering should it be separated DEPS or both in quotation | 07:49 |
| dcaliste | What do you mean "both in quotation" ? Should it be written like "DEPS Qt5Core Qt5Gui" and not simply without the quotes ? | 07:51 |
| pvuorela | searched ecm_generate_pkgconfig_file documentation and it has [DEPS "<dep> [<dep> [...]]"] | 07:51 |
| dcaliste | Ah, good point. Fun enough, it works without the quotes (nemo-qml-plugin-calendar is also building fine). | 07:52 |
| dcaliste | Ok, I'm trying with quotes and will update the MR accordingly. Thank you for pointing it out. | 07:56 |
| dcaliste | I'm going to prepare a quick patch in sailfishos repo also. | 07:57 |
| pvuorela | dcaliste: appreciated! | 07:59 |
| dcaliste | Hopefully https://github.com/sailfishos/kf5-calendarcore/pull/4 may solve the build issue. | 08:02 |
| chriadam | tyvm | 08:04 |
| chriadam | dcaliste: I have another meeting now, so I am going to have to head off | 08:05 |
| chriadam | thanks for your efforts as always! every much appreciated | 08:05 |
| dcaliste | No problem chriadam, we can speak about the QML binding for Buteo next week. | 08:05 |
| chriadam | if there is some PR which still needs attention from our side, please poke me on the PR :-) | 08:05 |
| chriadam | yep, sounds good, thanks | 08:05 |
| chriadam | have a great week! | 08:05 |
| * chriadam -> away | 08:05 | |
| flypig | dcaliste, you mentioned you might put together an article about Buteo. Is this still a possibility? It'd be really nice, but no pressure. | 08:06 |
| dcaliste | flypig, yes, I would, is the next deadline next Sunday ? | 08:06 |
| flypig | dcaliste, Sunday 19th, yes. | 08:06 |
| flypig | But it can go in the one after if that's not good. | 08:07 |
| dcaliste | It's fine for Sunday 19th. I can have something ready for review during the week 13th-19th. | 08:08 |
| flypig | That would be really super. | 08:08 |
| dcaliste | Before would have been a bit difficult, I've got some lengthy project review to finish before the 14th. | 08:08 |
| flypig | It's no problem. The timescale is entirely for you to set. | 08:09 |
| flypig | Just let me know nearer the time if you can get something to me, if so, that would be great, if not, no problem. | 08:09 |
| dcaliste | Yeh, thanks, but you should be able to count on it after the 14th and before the 19 th ! | 08:09 |
| flypig | Great :) | 08:09 |
| flypig | Thanks dcaliste. | 08:09 |
| dcaliste | pvuorela, ping me if the fix is not fixing the build issue. | 08:25 |
| pvuorela | dcaliste: sure. going now in. | 08:25 |
| pvuorela | dcaliste: looking good now | 08:48 |
| *** amccarthy_ is now known as amccarthy | 23:07 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!