| *** zbenjamin is now known as Guest28502 | 01:40 | |
| *** zbenjamin_ is now known as zbenjamin | 01:40 | |
| *** frinring_ is now known as frinring | 01:53 | |
| *** SpeedEvil is now known as Guest59647 | 02:50 | |
| *** nyov is now known as Guest35433 | 03:52 | |
| dcaliste | Hello chriadam, I hope you're well. | 06:48 |
|---|---|---|
| chriadam | hi dcaliste | 06:52 |
| chriadam | yes, doing well, thanks. how are you? | 06:53 |
| dcaliste | I'm ok, thanks. | 06:53 |
| chriadam | great | 06:54 |
| chriadam | I saw that Pekka has been reviewing a few PRs you've made - I hope that they're progressing nicely? | 06:54 |
| dcaliste | As you may have noticed, I've started to publish the pieces to get the log browsable in UI. | 06:54 |
| dcaliste | Indeed pvuorela accepted already the bits for mKCal. | 06:55 |
| chriadam | we're currently transitioning a bunch of repositories from gitlab to github and my understanding is that the PRs can't be migrated | 06:55 |
| chriadam | so we either need to merge things, or recreate PRs after the migration | 06:55 |
| dcaliste | Yeh, I've seen that many pending MRs were sorted out and accepted or closed. | 06:56 |
| dcaliste | No problem to reopen a PR in Github if they don't get accepted in time in Gitlab. | 06:56 |
| chriadam | great :-) thanks. | 06:57 |
| chriadam | are there any PRs which I should review, currently? | 06:57 |
| chriadam | I've been working mostly on something else recently and haven't had time to follow things | 06:57 |
| dcaliste | You can read this MR description https://git.sailfishos.org/mer-core/mkcal/merge_requests/60 if you didn't have time to do it yet. | 06:59 |
| dcaliste | The MR has been accepted, but the description gives a broader overview of the path to get the log in the UI. | 06:59 |
| dcaliste | After this mKCal addition, there is this one in nemo-qml-plugin-calendar : https://git.sailfishos.org/mer-core/nemo-qml-plugin-calendar/merge_requests/84 | 07:00 |
| dcaliste | For the latter, actually, I'm going to modify it to make it more minimal. | 07:00 |
| chriadam | right, that's the "event instance model" similar to agenda model? | 07:01 |
| dcaliste | At the moment, it contains changes to use the instanceIdentifier to sort the internal storage of events, instead of QMultiHash, but it's not strictly speaking necessary and it may bring issues. | 07:01 |
| dcaliste | Yes, it is introducing an EventList model. | 07:02 |
| dcaliste | Basically, I'm going to keep only the last commit of this MR at the moment. | 07:02 |
| chriadam | when you say "it may bring issues" do you mean that there is some issue you've encountered, or do you just mean that it increases the likelihood of bugs just because more is changing? | 07:04 |
| chriadam | I kind of like the idea of getting rid of QMultiHash and using unique instanceIdentifier keys, honestly ;-) but I agree that more changes = more risk | 07:05 |
| dcaliste | Using the instanceIdentifier to store Events in QHash in my opinion is a good idea, instead of QMultiHash, it simplifies things. There is one potential issue that I see, and I would like to address first in KCalendarCore, that is : | 07:06 |
| dcaliste | - instanceIdentifier is built by concatenating the UID and *a* string representation of the recurrenceId, | 07:07 |
| dcaliste | - the recId is a QDateTime and it may have several string representation for the same date, even when using the same Qt::ISODate format, | 07:07 |
| chriadam | even when using ISODate format? how so? | 07:08 |
| dcaliste | - for instance, 20210511T090800Z and 20210511T090800+0000 represent the same date but are not the same strings. | 07:08 |
| chriadam | ah. | 07:08 |
| chriadam | true. | 07:08 |
| chriadam | what is the solution? provide some "canonical" recurrentIdString() method, which is used when building the instanceIdentifier, or? | 07:09 |
| dcaliste | So if QML is changing the QDateTime in that direction, then the store may thing that the event should be reloaded. | 07:09 |
| dcaliste | I would like to force UTC conversion of the recId in KCalendarCore instanceIdentifier() function before the string conversion. | 07:10 |
| dcaliste | Like that we're sure to use a unique string representation for the same date time even if given in different time spec. | 07:11 |
| chriadam | would that ensure date strings like 20210511T090800Z rather than 20210511T090800+0000 ? | 07:11 |
| chriadam | I guess the second is some "zero offset from utc" spec, whereas the first is "utc" spec | 07:12 |
| dcaliste | Like that we're sure that event1.uid == event2.uid && event1.recid == event2.recId can be tested as event1.instanceIdentifier() == event2.instanceIdentifier(). | 07:12 |
| dcaliste | Indeed, the two representations means different spec, but the == of QDateTime is true. | 07:12 |
| dcaliste | It would force the stringification of the recid to be always in UTC. | 07:13 |
| chriadam | makes sense. | 07:13 |
| dcaliste | It ensures that recId1 == recId2 is equivalent to recId1.toUTC.toString == recid2.toUTC.toString | 07:13 |
| dcaliste | Otherwise, there are cases where recid1 == recid2 is not equivalent to recId1.toString == recid2.toString | 07:14 |
| dcaliste | See the example given before. | 07:14 |
| chriadam | yep, makes sense. I'm trying to think of some case where we'd want them to produce different identifiers, but I cannot | 07:15 |
| chriadam | e.g. I was thinking "Hmm, could you have some event like 'new years eve celebrations in timezone X' and 'new years eve celebrations in timezone Y' where both timezones have the same offset but they're different... | 07:16 |
| chriadam | but I don't think that makes sense | 07:16 |
| dcaliste | I need to convince the people from KCalendarCore to add this toUtc() conversion in the instanceIdentifier() function ;) I'm thinking of a test case with the above example to demonstrate the necessicity. | 07:16 |
| dcaliste | About your case, there are two events, with two different UIDs. This stuff is for exceptions only for a given event. | 07:17 |
| chriadam | true of course. | 07:17 |
| dcaliste | And you can have only one exception for a given occurrence, and this exception is defined by the date and time of the original occurrence. | 07:17 |
| dcaliste | i.e. the recurrenceId. | 07:18 |
| dcaliste | But the RFC does not speak about the way to represent this uniaue date and time. | 07:18 |
| chriadam | right. having two exceptions on the same date isn't possible, so the only thing we need to ensure is that the string value of the RID is round-trip stable etc. yep, makes sense. | 07:18 |
| chriadam | do you think that the toUtc() will be accepted? I can't see why it wouldn't be. | 07:19 |
| chriadam | unless some folks somehow depend on the current format, and if currently the offset format is preferred | 07:19 |
| dcaliste | And since we can have several strings for the same date at the moment, the instanceIdentifier for a unique exception may not be uniaue. That's the potential issue I forsee. | 07:19 |
| dcaliste | I'm not sure that they will accept immediately, because some people may rely on already stored instanceIdentifiers... | 07:20 |
| dcaliste | If their RecIDs were UTC, no change, but if not they won't find their incidence anymore. | 07:20 |
| dcaliste | Reversely, if I force a offset representation, UTC people will losse their stored incidences... | 07:21 |
| chriadam | indeed.. | 07:22 |
| dcaliste | So the safest at the moment, is not to use the instanceIdentifier to sort our events in nemo-qml-plugin-calendar ;) | 07:23 |
| chriadam | makes sense. | 07:23 |
| chriadam | thank you for your thoroughness | 07:23 |
| dcaliste | For an mKCal search, on the contrary, it's not an issue. | 07:23 |
| dcaliste | Because, we're reversely extracting the QDateTime from the instanceIdentifier and then the == will work. | 07:24 |
| dcaliste | So I'm going to change only the call to the calendar worker to use instanceIdentifiers instead of UID as done at the moment and build the EventList model with instanceIdenfier keys over it. | 07:25 |
| chriadam | if KCalendarCore don't accept the change upstream, we can apply it to our repo anyway, I guess. but only if we have to... hopefully they accept the patch. | 07:25 |
| dcaliste | Yep, let see. Anyway, I need to prepare the MR upstream with a test case and some detailed arguments with the pros and cons. | 07:28 |
| chriadam | thanks | 07:28 |
| dcaliste | Now all of this relies on https://git.sailfishos.org/mer-core/buteo-syncfw/merge_requests/43 | 07:28 |
| dcaliste | Which brings QML bindings to the Buteo logs and create models for list views. | 07:29 |
| dcaliste | It's more or less ready for thorough review I think, at last after one year ! | 07:30 |
| dcaliste | It is declaring everything under SyncResults as Q_GADGET to use these class as lightweight objects from QML. | 07:30 |
| chriadam | pvuorela: flypig: ^ we should set aside some time soon to review this one | 07:31 |
| dcaliste | This includes the SyncResults and the TartgetResult, plus the helping structs like the ItemCounts. | 07:31 |
| dcaliste | In addition, it is creating a new QML plugin under libbuteosyncfw/plugin to expose these types. | 07:32 |
| dcaliste | Most of them are uncreatable but can be retrieve through two new objects : | 07:32 |
| dcaliste | - SyncProfileWatcher | 07:33 |
| dcaliste | - SyncResultModel and MultiSyncResultModel | 07:33 |
| dcaliste | The first one is a QML representation of a profile, read-only at the moment, from which we can get its properties, sync schedule and sync log. | 07:34 |
| dcaliste | The second are model to display a list of SyncResults, either from a unique profile or from severql profiles. | 07:34 |
| dcaliste | All are dynamic objects that changes when the profile or the log are changed, thanks to the SyncClientInterface object from Buteo. | 07:35 |
| dcaliste | The latter list model can be used to display a list of all buteo logs on the device, like the transfer list in setting. | 07:36 |
| dcaliste | Then, one can tap on a particular log entry and view possible details if any, like in the screenshot from the mKCal MR I've mentioned above. | 07:37 |
| dcaliste | As you suggested earlier, this dedicated page for each sync plugin, can be opened in the corresponding application via a DBus call. | 07:38 |
| dcaliste | In the example I gave in the MR, it's still in one single application for simplicity reason for demonstrating it. But it's something that could be discussed together with jpetrell and Martin if they want to. | 07:40 |
| chriadam | the MR also has some QML code to demo/test, I see. thanks. there is JB#49486 which corresponds to this "sync errors UI" work | 07:40 |
| chriadam | I will poke some people internally, not sure if Martin will get a chance to look at it soon, but hopefully Joona will | 07:40 |
| dcaliste | For the QML to demo it, I need to update it. I think I changed one or two things since the initial message ! | 07:43 |
| dcaliste | No problem to reuse this JB id, even if the main part is not to show errors, but simply to give a feedback on what happen behind the scene. Like : oh, I got two new events synced from this shared calendar, what are they ? | 07:44 |
| chriadam | that's a good point | 07:46 |
| chriadam | it's not just errors, but also information about new data on device | 07:46 |
| chriadam | hmm. I guess there's some overlap between that and notifications | 07:46 |
| chriadam | anyway, I've pinged Joona internally, and also added bea and david to the MR | 07:47 |
| chriadam | I will take a look at it sometime this week, not sure what level of detail I will get to, though. | 07:48 |
| chriadam | thanks for that - it was a long road, you put a lot of effort in to get it to this point, thanks very much! | 07:48 |
| dcaliste | Indeed, we're receiving notfications for new emails, we may receive notification for new events in calendar too ! But even, it can be upstreaming information that you would like to check, like : "hey, I see that the new event has been upsynced last night, you should see it on your device !" | 07:48 |
| chriadam | right, true | 07:49 |
| chriadam | were there any other topics to cover, this week? was there anything from last meeting which I had forgotten to follow up on? | 07:53 |
| chriadam | did MartinS ever get back to you, regarding the calendar timezone shift PR? | 07:53 |
| dcaliste | No I didn't receive any message from Martin yet about the clock change MR. I guess he still very busy ! | 07:54 |
| dcaliste | Besides, I think, we discussed all about the pending MR today. Thanks for the discussion. | 07:54 |
| chriadam | ok, I will poke Martin again | 07:55 |
| dcaliste | We can postpone this one for next week : https://git.sailfishos.org/mer-core/mkcal/merge_requests/63 | 07:55 |
| chriadam | I guess he's busy with 4.1.0 activities, but hopefully very very soon he will have some time to look at that timezone shift one properly | 07:55 |
| dcaliste | It's mainly cosmetic but with a potential for disaster ! | 07:55 |
| chriadam | ah ;-) | 07:55 |
| chriadam | well, yes, let's discuss next week. i will take a look later this week and think about it ;-) | 07:56 |
| chriadam | ok, thanks again! have a great week! see you next week. | 07:56 |
| * chriadam -> away, gnight | 07:56 | |
| dcaliste | Thank you , you too. | 07:56 |
| *** Zuccace is now known as Zucca | 09:07 | |
| frojnd | Hi there. | 14:18 |
| frojnd | How can I search for a package with pkcon? | 14:18 |
| frojnd | MLS Manager is doing some thing and I can't use openrepos anymore because something related to MLS Manager app. I would like to remove it from pkcon | 14:19 |
| frojnd | But not sure how to search for it.. | 14:19 |
| mal | pkcon search package_name should work | 14:20 |
| mal | that package name doesn't need to be complete | 14:20 |
| frojnd | Hm I still get the same message now from terminal: Fatal error: File './harbour-mls-offline-hr-2021.04.04-1.noarch.rpm' not found on medium 'https://mls-offline-repo.nubecula.org/' | 14:22 |
| frojnd | I think I removed the wrong package | 14:23 |
| frojnd | I removed harbour-mlsmanager but I think I should remove harbour-mls-offline | 14:23 |
| frojnd | Confusion | 14:24 |
| frojnd | https://termbin.com/5pquf | 14:25 |
| frojnd | This is the output I get while trying to remove harbour-mlsmanager | 14:26 |
| frojnd | Can I somehow force it | 14:26 |
| mal | try doing "pkcon refresh" first | 14:26 |
| frojnd | Ok it's refreshing | 14:27 |
| frojnd | That was it mal! Thank you | 14:30 |
| frojnd | While removing package it had to update packages? | 14:30 |
| *** vilpan is now known as Guest89008 | 14:44 | |
| *** Guest89008 is now known as vilpan | 14:44 | |
| mal | yes | 14:51 |
| mal | it was replacing some packages during the removal and the repo status not up to date so it needed to be refreshed | 14:52 |
| elros1 | actually that is bug somwhere in pkcon, it always upgrade everything. On ubuntu it doesn't | 15:18 |
| Mister_Magister | Protip to videos recorded on sfos: ffmpeg -i in.mp4 -vcodec libx264 -crf 30 out.mp4 | 16:16 |
| Mister_Magister | cuts size in 10, removes abundance of duplicated frames, and retains quality | 16:17 |
| Mister_Magister | ffmpeg will scream at you with More than 1000 frames duplicated | 16:18 |
| Mister_Magister | i'm already at 1800 duplicated frames lma o | 16:18 |
| mal | Mister_Magister: that seems strange | 16:39 |
| Mister_Magister | mal: not really | 16:39 |
| Mister_Magister | standard for any sfos phone | 16:39 |
| Mister_Magister | when i will be adding recordign in my telegram app i will reencode video on the fly with those parameters | 16:40 |
| Mister_Magister | cause f*** sfos recording encoding | 16:40 |
| mal | Mister_Magister: the encoding is done in android side | 16:51 |
| mal | unless we have some wrong settings for that | 16:52 |
| Mister_Magister | somehow android vids arent as bad | 16:52 |
| mal | maybe we use wrong profile or something | 16:52 |
| Mister_Magister | you think its worth investigating? | 16:52 |
| Mister_Magister | like i have 5z with advanced camera. you have video bitrate slide but no matter the slider bitrate sucks | 16:53 |
| Mister_Magister | and 4K is recorded with such shit bitrate | 16:53 |
| Mister_Magister | and 720p video on my g2 with 9min lenth is 1GB | 16:53 |
| Mister_Magister | when reencoded its 50MB | 16:53 |
| mal | probably should be investigated | 16:53 |
| Mister_Magister | what about dash in gstreamer? any info from jolla? | 16:54 |
| mal | no news about dash | 16:59 |
| Mister_Magister | mal: thanks | 17:21 |
| *** BitEvil is now known as SpeedEvil | 17:31 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!