| *** zbenjamin_ is now known as zbenjamin | 01:11 | |
| dragonchaser | morning | 04:29 |
|---|---|---|
| dragonchaser | is it possible that on the xa2 beta, android apps only can access mediafiles on the internal storage? | 04:29 |
| ViGe | dragonchaser: Yes, I believe that is the case at the moment | 04:48 |
| dragonchaser | ViGe: ok, good to know, then I will no longer try to find the issue, thx | 04:48 |
| ViGe | dragonchaser: I just happened to open together.jolla.com. I suggest you do the same; The top post is howto mount the sd card in alien :) | 04:54 |
| dragonchaser | ViGe:nice, but I would assume that this will be resolved in the next release (or the one after that) for now I only need it to access the camera roll from signal and for this saving to the internal storage does the trick | 04:56 |
| r0kk3rz | did you encrypt the sd card? | 05:12 |
| dragonchaser | r0kk3rz: no | 05:17 |
| dcaliste | Hello chriadam, how are you ? | 06:56 |
| chriadam | dcaliste: Hi, I'm well thanks. How are you? | 06:57 |
| dcaliste | I'm fine thanks. Thanks also for the PR in secrets. | 06:57 |
| chriadam | no, thank you. I have another PR (minor doc fix) which I hope to merge tonight, then I will tag | 06:58 |
| chriadam | I didn't get a chance to properly test the caldav PR yet unfortunately, but will do so as soon as I can | 06:58 |
| dcaliste | Yes, it's ok, I've seen it. By the way, I'm wondering if the secret doc is published on sailfishos wiki somewhere ? | 06:58 |
| chriadam | for the jolla-calendar fix, it's fine for me, but was hoping pvuorela would also approve | 06:59 |
| chriadam | no, the docs aren't published currently. I think it might be included in upcoming SDK, but not 100% sure. | 06:59 |
| dcaliste | It would be nice I think. Some people may want to use it and increasing user base is the best way to test it and polish the API if needed. | 07:00 |
| dcaliste | The doc is quite well done with examples… | 07:00 |
| dcaliste | Particularly with the disclaimer you're adding, it's safe with respect to stability warnings ;) | 07:01 |
| chriadam | I agree that increasing the amount of use would be very helpful to find issues and improve it. there are things we know are missing (message authentication codes, key exchange, certificate handling, etc) | 07:01 |
| chriadam | but it's still useful for a variety of use cases currently, I think | 07:01 |
| chriadam | in regards to documentation, definitely could spend easily a week polishing/improving the docs honestly, but there's no budget for that currently. and it's probably "good enough" currently | 07:02 |
| chriadam | I'd ideally like a crypto expert to review the internal stuff to make sure heinous errors were not made... | 07:04 |
| dcaliste | Yes, but I don't know any :( | 07:06 |
| chriadam | nor I | 07:06 |
| chriadam | ah well | 07:06 |
| chriadam | unfortunately jpetrell is away until Thursday | 07:06 |
| chriadam | it seems he hasn't given a tick to the jolla-email PR yet still | 07:07 |
| ViGe | chriadam: Care to share URL for the doc fix PR? | 07:07 |
| dcaliste | Indeed. | 07:07 |
| chriadam | https://github.com/sailfishos/sailfish-secrets/pull/160/files | 07:07 |
| chriadam | not a fix, just adding a disclaimer | 07:07 |
| ViGe | thanks :) | 07:07 |
| chriadam | dcaliste: hrm, I saw pvuorela merged that mkcal fix, but I don't see a tag for that one yet | 07:08 |
| chriadam | I will tag it | 07:09 |
| chriadam | is there a mer bug number associated with that one? | 07:09 |
| dcaliste | chriadam, pvuorela: thanks for the mkcal MR merge, about the jolla-calendar PR, yes that's nice if you can accept it also ;) | 07:09 |
| dcaliste | chriadam: no, no MER bug, I thought the MER bug tracker has became read-only… | 07:09 |
| chriadam | I don't believe lbt has flipped the switch on that yet | 07:10 |
| dcaliste | But if not, I can create one, no problem. | 07:10 |
| dcaliste | It would be nice to keep public track of the issue for later purpose, if required. | 07:10 |
| chriadam | at least, I created a bug earlier today (MER#2040) for the caldav PR | 07:10 |
| chriadam | ViGe: thanks :-) | 07:11 |
| dcaliste | chriadam: https://bugs.merproject.org/show_bug.cgi?id=2041 | 07:14 |
| merbot | Mer bug 2041 in mkcal "Recurrent event with a duration are not restored as saved because of end date being present" [Task,New] | 07:14 |
| chriadam | ty | 07:14 |
| dcaliste | I'm reading bug#2040 now… | 07:15 |
| chriadam | wait... tag 0.4.9 does exist and package was accepted... weird.. | 07:16 |
| chriadam | sorry my bad. have closed that bug now linked to commit | 07:17 |
| dcaliste | About https://bugs.merproject.org/show_bug.cgi?id=1982, I'm curious how we can arrive in this situation. Normally, the remoteUrisEtags that is used by the calculateDelta() function will see that local event without ETAG and URI is present in remote and will add the URI and ETAG before pushing it again. | 07:17 |
| merbot | Mer bug 1982 in buteo-sync-plugin-caldav "CalDAV PUT upsync fails due to partially-completed previous sync cycle" [Task,New] | 07:17 |
| dcaliste | But this is a recent correction by the way… | 07:18 |
| dcaliste | Looking at git blame… | 07:18 |
| chriadam | that bug probably pre-dates recent stuff. I don't even remember who sent me that log. | 07:18 |
| dcaliste | Lines to treat this were added in September 2018 (lines 886 and 887 in master). | 07:19 |
| chriadam | hmm, interesting. that's before that bug report was raised (november 2018) but it's possible that the community member was using an older version (since it seems unlikely that we released that fix to public so soon after being merged/tagged) | 07:20 |
| dcaliste | Ah, except if the event was then modified locally before next sync… | 07:21 |
| dcaliste | Let me check that scenario… | 07:21 |
| dcaliste | In that scenario, the lines to correct this were added the 20th of November 2018 | 07:22 |
| dcaliste | So I guess, it should not happen now. As a bonus, the PR associated to #2040 will highly mitigate the cases like that since URI and ETAG will be added as soon as we know that they are on server and not only if full sync is successfull. | 07:23 |
| chriadam | yes | 07:23 |
| chriadam | the only thing I'm unsure about is: do we roll back transactions in any error case? | 07:24 |
| dcaliste | No, we don't rollback anything, we just abort. | 07:24 |
| chriadam | ok | 07:24 |
| chriadam | great | 07:24 |
| dcaliste | There is a comment somewhere I think talking about rollback, but there is no actual code to do it ;) | 07:24 |
| chriadam | hah | 07:25 |
| chriadam | interesting | 07:25 |
| dcaliste | But I prefer the way it is working now: all that has been successfully upsynced is marked as upsynced on device. | 07:26 |
| dcaliste | I would even prefer to also save on device what has been downloaded already even in the case some upsync fails or even some local saving fail. | 07:26 |
| dcaliste | Indeed, that would make the device copy closer to the server one, than aborting any local saving on one error. | 07:27 |
| albertux | chriadam: in the last release seems not solved yet "contactsd" drain problem... | 07:28 |
| chriadam | I tend to agree, although I'd like to be certain that some error cases couldn't cause bad issues (e.g. if an event series is moved from one calendar to another, for example, an error halfway through might see that the series was removed from one calendar but then not see it added to the other, etc) | 07:29 |
| chriadam | albertux: we haven't made the "prevent non-privileged sync" change yet. the workaround I gave you was a quick-dirty fix, but to do it properly we need to remove the databases from devices, check that our other integration points are cleaned up (e.g. alien), remove dead code from contactsd, etc. | 07:30 |
| chriadam | albertux: and unfortunately that one isn't currently a priority so it's on the backburner for now | 07:30 |
| albertux | chriadam: ok, no problem, I'll continue to sync manually, don't be afraid.. ;) | 07:31 |
| chriadam | albertux: thanks for your patience :-( | 07:31 |
| chriadam | hopefully it's something we will address in the near future | 07:31 |
| chriadam | when we do some much needed maintenance of our contacts stack | 07:32 |
| chriadam | dcaliste: it could be that storage->save() calls trigger transaction commit? | 07:32 |
| chriadam | if a storage->close() is done without a storage->save() I wonder whether a transaction rollback occurs? | 07:32 |
| dcaliste | Ah, that's called a rollback, then ok, there is one ;) | 07:33 |
| dcaliste | I thought that since nothing was actually written on disk, there was no actual rollback. | 07:33 |
| dcaliste | Yes, in case of any error, nothing is changed on disk locally. | 07:33 |
| chriadam | dcaliste: right - does that mean that 1982 can still occur? | 07:34 |
| dcaliste | No, I don't think so. | 07:34 |
| chriadam | e.g. we do a put, then some error occurs, so the database will not contain the etag/href for the event we put up? so next sync, we try to put again? or will the commits you mentioned ensure that we update the local db with the server-side etag/href prior to attempting to upsync? | 07:35 |
| dcaliste | Thanks to lines 887 and 975 in notebooksyncagent.cpp master. | 07:35 |
| dcaliste | The MR of #2040 is not necessary, it should work already. | 07:35 |
| chriadam | aha, I see, yes, thanks | 07:35 |
| dcaliste | Because on next sync after failure, the URI and ETAG are added in memory in the mentioned lines before up syncing again. | 07:36 |
| chriadam | indeed | 07:37 |
| chriadam | thanks | 07:37 |
| dcaliste | I agree that the "rollback" is making early etag saving useless in #2040. We need to add a storage->save() before proceeding to local update from server events… | 07:37 |
| dcaliste | (forgot useless before the full stop punctuation…) | 07:38 |
| chriadam | btw sailfish-secrets 0.2.11 was accepted by CI so that one includes your cancel+timeout and error handling fixes - thanks | 07:38 |
| dcaliste | chriadam: great ;) | 07:38 |
| dcaliste | Because piece by piece, all requirements for GPG stuff is going in, like the QMF server already saving the emails properly… | 07:39 |
| chriadam | dcaliste: that's an interesting idea, sort of breaking the sync into two parts: upsync from local (then save()) + downsync from server (then save()) | 07:39 |
| dcaliste | chriadam: yes, I'll amend the the MR accordingly. | 07:39 |
| chriadam | I will need to have a think about whether that could possibly cause unwanted side effects. I can't think of any off the top of my head. | 07:40 |
| dcaliste | Sure… | 07:41 |
| dcaliste | chriadam, pvuorela: following https://www.volkerkrause.eu/2019/04/27/kf5-kcontacts-and-kcalcore.html I'm working on compiling upstream in SDK. | 07:43 |
| dcaliste | It's working not too badly, some adjustments are required due to older Qt version. | 07:43 |
| chriadam | does it require many more dependencies? or is it fairly contained? | 07:43 |
| dcaliste | It is a nice cleaning of KCalcore. It has no dependencies from libical. | 07:44 |
| dcaliste | It has no remains of KDateTime and other K stuff. | 07:44 |
| pvuorela | ooh. | 07:45 |
| dcaliste | The API seems to be untouched which is nice (beside moving from KDateTime to QDateTime). | 07:46 |
| chriadam | I wonder how that might affect e.g. nemo-qml-plugin-calendar etc. ISTR we use KDateTime etc there also. would be nice to switch to QDateTime if QDateTime now supports all of the timezone and timespec (e.g. ClockTime) stuff we need | 07:46 |
| dcaliste | Disadvantage: need to adjust mkcal and nemo-qml-plugin-calendar accordingly. | 07:47 |
| dcaliste | So still a lot of work, but it's a nice move I think. | 07:49 |
| chriadam | would be nice to have an upstream which actively maintains kcalcore. I worry about whether there might be edge cases which now act differently since they no longer use libical | 07:50 |
| dcaliste | They plan to put Kcalcore into KF5 in Sept/Oct this year. | 07:51 |
| chriadam | but I agree probably worth the effort. I will raise it with Joona - not sure there's resourcing for such internally at the moment, but perhaps once the next release is out, we can spend some time porting mkcal/nqpc + various plugins like google-calendar etc | 07:51 |
| dcaliste | I will take care of OSS parts I think like mkcal. | 07:51 |
| chriadam | that would definitely be helpful, thank you :-) | 07:56 |
| chriadam | just to summarise current outstanding PRs: 1) caldav PR - chris needs to test, dcaliste will look into save() at halfway point. 2) jolla-calendar PR - hoping pvuorela can approve that one. 3) jolla-email PR - waiting for Joona to get back and then I will poke him. | 07:58 |
| dcaliste | I will keep you both informed, I will push soon the kcalcore in a new kf5-kcalcore repo. | 07:58 |
| chriadam | thanks | 07:58 |
| dcaliste | chriadam: I'm fine with summary of today. | 08:00 |
| chriadam | dcaliste: great. hopefully will get those last two sorted this week. | 08:03 |
| chriadam | thanks again for your time and effort | 08:03 |
| dcaliste | That's fun, thank you for your help and have a nice week. | 08:06 |
| chriadam | you too :-) | 08:06 |
| wr | sail works on honor v20? | 09:22 |
| r0kk3rz | no | 09:23 |
| nuke5_ | hi, have strange problem with upgrade to 3.0.3.9 from 3.0.2.8 Xperia X dual SIM | 09:33 |
| nuke5_ | after clicking update phone reboots, start instaling update and then inform that update fail. I reboot using power button. | 09:37 |
| nuke5_ | After some time phone inform that there is the same update, after downloanding the same bug | 09:38 |
| nuke5_ | I am new to Sailfish so aprishiate for strait forward answer | 09:40 |
| dragonchaser | nuke5_: friend of mine had the same bug, found no way to resolve he reflashed the phone | 09:45 |
| mal | sometimes running "ssu release 3.0.3.9" and then "version --dup" to update helps | 09:54 |
| mal | in terminal using devel-su (i.e. set password in developer mode) | 09:55 |
| *** Renault_ is now known as Renault | 10:11 | |
| nuke5_ | mal: THX, works for me | 10:24 |
| nuke5_ | also, is there right now any working client for Signal/Telegram/Whatsapp, not from Android store? | 10:34 |
| zebbiz_pi | nuke5_: I use Whisperfish, which is pretty good | 10:36 |
| zebbiz_pi | That's only signal, though | 10:36 |
| nuke5_ | https://github.com/aebruno/whisperfish | 10:40 |
| nuke5_ | ? | 10:40 |
| nuke5_ | >Project Status | 10:40 |
| nuke5_ | This project is no longer maintained. Do not use this client. | 10:40 |
| r0kk3rz | theres an assortment of telegram clients | 10:41 |
| nuke5_ | for Signal is posible download apk from official website | 10:41 |
| r0kk3rz | not sure which is the best currently | 10:41 |
| r0kk3rz | no whatsapp because whatsapp is bad | 10:42 |
| nuke5_ | r0kk3rz: any working for telegram will be good. But there is no in the jolla shop | 10:43 |
| r0kk3rz | yeah openrepos.net has more apps than jolla | 10:45 |
| dcaliste | pvuorela, chriadam: packaging of new upstream kcalcore https://git.merproject.org/dcaliste/kf5-calendarcore (I'm going to try to upstream patch 1 and patch 2). | 11:21 |
| *** frinring_ is now known as frinring | 12:37 | |
| *** zebbiz_pi is now known as kallekanin | 14:22 | |
| *** kallekanin is now known as zebbiz_pi | 16:58 | |
| Almindor | spiiroin: is there any other way I could contact jusa async to get the mce/audio sink issue sorted? I'm getting really close to releasing this and would like to not use the direct display on/off override | 17:16 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!