Tuesday, 2019-05-14

*** zbenjamin_ is now known as zbenjamin01:11
dragonchaseris it possible that on the xa2 beta, android apps only can access mediafiles on the internal storage?04:29
ViGedragonchaser: Yes, I believe that is the case at the moment04:48
dragonchaserViGe: ok, good to know, then I will no longer try to find the issue, thx04:48
ViGedragonchaser: 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
dragonchaserViGe: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 trick04:56
r0kk3rzdid you encrypt the sd card?05:12
dragonchaserr0kk3rz: no05:17
dcalisteHello chriadam, how are you ?06:56
chriadamdcaliste: Hi, I'm well thanks.  How are you?06:57
dcalisteI'm fine thanks. Thanks also for the PR in secrets.06:57
chriadamno, thank you.  I have another PR (minor doc fix) which I hope to merge tonight, then I will tag06:58
chriadamI didn't get a chance to properly test the caldav PR yet unfortunately, but will do so as soon as I can06:58
dcalisteYes, 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
chriadamfor the jolla-calendar fix, it's fine for me, but was hoping pvuorela would also approve06:59
chriadamno, the docs aren't published currently.  I think it might be included in upcoming SDK, but not 100% sure.06:59
dcalisteIt 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
dcalisteThe doc is quite well done with examples…07:00
dcalisteParticularly with the disclaimer you're adding, it's safe with respect to stability warnings ;)07:01
chriadamI 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
chriadambut it's still useful for a variety of use cases currently, I think07:01
chriadamin 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" currently07:02
chriadamI'd ideally like a crypto expert to review the internal stuff to make sure heinous errors were not made...07:04
dcalisteYes, but I don't know any :(07:06
chriadamnor I07:06
chriadamah well07:06
chriadamunfortunately jpetrell is away until Thursday07:06
chriadamit seems he hasn't given a tick to the jolla-email PR yet still07:07
ViGechriadam: Care to share URL for the doc fix PR?07:07
chriadamnot a fix, just adding a disclaimer07:07
ViGethanks :)07:07
chriadamdcaliste: hrm, I saw pvuorela merged that mkcal fix, but I don't see a tag for that one yet07:08
chriadamI will tag it07:09
chriadamis there a mer bug number associated with that one?07:09
dcalistechriadam, pvuorela: thanks for the mkcal MR merge, about the jolla-calendar PR, yes that's nice if you can accept it also ;)07:09
dcalistechriadam: no, no MER bug, I thought the MER bug tracker has became read-only…07:09
chriadamI don't believe lbt has flipped the switch on that yet07:10
dcalisteBut if not, I can create one, no problem.07:10
dcalisteIt would be nice to keep public track of the issue for later purpose, if required.07:10
chriadamat least, I created a bug earlier today (MER#2040) for the caldav PR07:10
chriadamViGe: thanks :-)07:11
dcalistechriadam: https://bugs.merproject.org/show_bug.cgi?id=204107:14
merbotMer bug 2041 in mkcal "Recurrent event with a duration are not restored as saved because of end date being present" [Task,New]07:14
dcalisteI'm reading bug#2040 now…07:15
chriadamwait... tag 0.4.9 does exist and package was accepted... weird..07:16
chriadamsorry my bad.  have closed that bug now linked to commit07:17
dcalisteAbout 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
merbotMer bug 1982 in buteo-sync-plugin-caldav "CalDAV PUT upsync fails due to partially-completed previous sync cycle" [Task,New]07:17
dcalisteBut this is a recent correction by the way…07:18
dcalisteLooking at git blame…07:18
chriadamthat bug probably pre-dates recent stuff.  I don't even remember who sent me that log.07:18
dcalisteLines to treat this were added in September 2018 (lines 886 and 887 in master).07:19
chriadamhmm, 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
dcalisteAh, except if the event was then modified locally before next sync…07:21
dcalisteLet me check that scenario…07:21
dcalisteIn that scenario, the lines to correct this were added the 20th of November 201807:22
dcalisteSo 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
chriadamthe only thing I'm unsure about is: do we roll back transactions in any error case?07:24
dcalisteNo, we don't rollback anything, we just abort.07:24
dcalisteThere is a comment somewhere I think talking about rollback, but there is no actual code to do it ;)07:24
dcalisteBut I prefer the way it is working now: all that has been successfully upsynced is marked as upsynced on device.07:26
dcalisteI 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
dcalisteIndeed, that would make the device copy closer to the server one, than aborting any local saving on one error.07:27
albertuxchriadam: in the last release seems not solved yet "contactsd" drain problem...07:28
chriadamI 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
chriadamalbertux: 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
chriadamalbertux: and unfortunately that one isn't currently a priority so it's on the backburner for now07:30
albertuxchriadam: ok, no problem, I'll continue to sync manually, don't be afraid..  ;)07:31
chriadamalbertux: thanks for your patience :-(07:31
chriadamhopefully it's something we will address in the near future07:31
chriadamwhen we do some much needed maintenance of our contacts stack07:32
chriadamdcaliste: it could be that storage->save() calls trigger transaction commit?07:32
chriadamif a storage->close() is done without a storage->save() I wonder whether a transaction rollback occurs?07:32
dcalisteAh, that's called a rollback, then ok, there is one ;)07:33
dcalisteI thought that since nothing was actually written on disk, there was no actual rollback.07:33
dcalisteYes, in case of any error, nothing is changed on disk locally.07:33
chriadamdcaliste: right - does that mean that 1982 can still occur?07:34
dcalisteNo, I don't think so.07:34
chriadame.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
dcalisteThanks to lines 887 and 975 in notebooksyncagent.cpp master.07:35
dcalisteThe MR of #2040 is not necessary, it should work already.07:35
chriadamaha, I see, yes, thanks07:35
dcalisteBecause on next sync after failure, the URI and ETAG are added in memory in the mentioned lines before up syncing again.07:36
dcalisteI 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
chriadambtw sailfish-secrets 0.2.11 was accepted by CI so that one includes your cancel+timeout and error handling fixes - thanks07:38
dcalistechriadam: great ;)07:38
dcalisteBecause piece by piece, all requirements for GPG stuff is going in, like the QMF server already saving the emails properly…07:39
chriadamdcaliste: 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
dcalistechriadam: yes, I'll amend the the MR accordingly.07:39
chriadamI 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
dcalistechriadam, pvuorela: following https://www.volkerkrause.eu/2019/04/27/kf5-kcontacts-and-kcalcore.html I'm working on compiling upstream in SDK.07:43
dcalisteIt's working not too badly, some adjustments are required due to older Qt version.07:43
chriadamdoes it require many more dependencies?  or is it fairly contained?07:43
dcalisteIt is a nice cleaning of KCalcore. It has no dependencies from libical.07:44
dcalisteIt has no remains of KDateTime and other K stuff.07:44
dcalisteThe API seems to be untouched which is nice (beside moving from KDateTime to QDateTime).07:46
chriadamI 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 need07:46
dcalisteDisadvantage: need to adjust mkcal and nemo-qml-plugin-calendar accordingly.07:47
dcalisteSo still a lot of work, but it's a nice move I think.07:49
chriadamwould 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 libical07:50
dcalisteThey plan to put Kcalcore into KF5 in Sept/Oct this year.07:51
chriadambut 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 etc07:51
dcalisteI will take care of OSS parts I think like mkcal.07:51
chriadamthat would definitely be helpful, thank you :-)07:56
chriadamjust 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
dcalisteI will keep you both informed, I will push soon the kcalcore in a new kf5-kcalcore repo.07:58
dcalistechriadam: I'm fine with summary of today.08:00
chriadamdcaliste: great.  hopefully will get those last two sorted this week.08:03
chriadamthanks again for your time and effort08:03
dcalisteThat's fun, thank you for your help and have a nice week.08:06
chriadamyou too :-)08:06
wrsail works on honor v20?09:22
nuke5_hi, have strange problem with upgrade to from Xperia X dual SIM09: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 bug09:38
nuke5_I am new to Sailfish so aprishiate for strait forward answer09:40
dragonchasernuke5_: friend of mine had the same bug, found no way to resolve he reflashed the phone09:45
malsometimes running "ssu release" and then "version --dup" to update helps09:54
malin terminal using devel-su (i.e. set password in developer mode)09:55
*** Renault_ is now known as Renault10:11
nuke5_mal: THX, works for me10:24
nuke5_also, is there right now any working client for Signal/Telegram/Whatsapp, not from Android store?10:34
zebbiz_pinuke5_: I use Whisperfish, which is pretty good10:36
zebbiz_piThat's only signal, though10:36
nuke5_>Project Status10:40
nuke5_This project is no longer maintained. Do not use this client.10:40
r0kk3rztheres an assortment of telegram clients10:41
nuke5_for Signal is posible download apk from official website10:41
r0kk3rznot sure which is the best currently10:41
r0kk3rzno whatsapp because whatsapp is bad10:42
nuke5_r0kk3rz: any working for telegram will be good. But there is no in the jolla shop10:43
r0kk3rzyeah openrepos.net has more apps than jolla10:45
dcalistepvuorela, 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 frinring12:37
*** zebbiz_pi is now known as kallekanin14:22
*** kallekanin is now known as zebbiz_pi16:58
Almindorspiiroin: 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 override17:16

Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!