Tuesday, 2019-04-30

*** zbenjamin is now known as Guest8348701:13
*** zbenjamin_ is now known as zbenjamin01:13
sb0FYI, the bootloader in my H4133 phone incorrectly reports the model number as H3113, and this breaks the flashing script as it is03:32
sb0sailfishos otherwise works correctly on that phone03:33
r0kk3rzdid you ever put on lineageoos?04:09
r0kk3rzthat could have been what did it04:21
sb0so, lineageos modifies the bootloader?04:22
r0kk3rznot sure, ive only heard of that happening on one other device, and it seemed like lineageos did it04:23
dcalisteHello chriadam and jpetrell. I hope you had a pleasant vacation time, Chris.06:48
jpetrelldcaliste: hi :)06:49
chriadamdcaliste: hi!  yes, I did thank you.  I hope your easter break was nice also06:49
dcalisteFine also, thank you. The weather is going to the sunny period on this side of the planet ;) I've mainly worked at the same time on the CalDAV plugin.06:50
chriadamI saw some PRs but haven't yet had a chance to look at those ones06:51
dcalisteBut before, I've also addressed the lastest notes from pvuorela on the email client, about using a property to avoid warning if the signature files are not installed.06:52
dcalistechriadam: on CalDAV, there is a false positive detection of modified incidence when comparing remote and local for recursive event with a fixed number of occurences.06:52
chriadamwhat is the effect?  every sync cycle detects a remotely-modified?06:53
dcalisteThis is this MR: https://git.merproject.org/mer-core/kcalcore/merge_requests/706:53
dcalisteNo it is detecting a local modification.06:54
dcalisteThe issue is that endDate is used in the operator== even when it is not used because of a duration (fixed number of occurences).06:55
dcalisteI've explained everything in the MR.06:56
chriadamdid you see https://www.volkerkrause.eu/2019/04/27/kf5-kcontacts-and-kcalcore.html ? seems like kde upstream may be spending some effort on kcalcore in the future.  not sure.06:56
chriadamprobably doesn't affect us since they did some akonadi-based refactoring at some point, and we don't use akonadi etc06:56
chriadambut thought I'd mention it.06:57
dcalisteNice if Kcalkore is developped again.06:57
chriadamthat MR seems very simple in terms of code change, but I'll need to digest the description in the commit to make sure I understand why it's doing what it's doing ;-)06:58
chriadamthanks for that06:58
dcalisteGood, thank you.06:58
dcalisteThe MR in caldav plugin is much more ambitious: https://git.sailfishos.org/mer-core/buteo-sync-plugin-caldav/merge_requests/4207:00
dcalisteThere are minor bug corrections for specific corner cases, but also a lot of refactoring.07:01
dcalisteDo you prefer several small MRs, or you can review each commits of the MR?07:01
chriadamI can review the commits07:02
chriadamno problem07:03
chriadamlots of work there07:05
chriadamthanks for that07:06
chriadamI can't promise when I will get a chance to look at those07:06
chriadambut hopefully later this week07:06
chriadamon the gpg signature side of things, i don't think jpetrell or pvuorela had a chance to review those further while I was away unfortunately07:06
chriadamI'll try to progress those and get them merged/tagged this week or next week.07:06
dcalisteI can understand. It's part of the major refactoring I'm planning since a long time. Some parts were localised and "small", so I decided to include them earlier.07:07
dcalisteThere is another MR: https://git.sailfishos.org/mer-core/buteo-sync-plugin-caldav/merge_requests/4307:07
dcalisteThis one is orthogonal to the previous and is implementing a long lasting request in TJC about the ability to rescan the calendars.07:08
chriadamah, instead of merely on account creation07:08
dcalisteIt is finally quite easy to add a propfind request at the beginning of each sync cycle.07:08
dcalisteThe only issue that I noticed is with the account setting page: to test it, I'm in the account setting page of my test CalDAV account. I trigger there the sync pulley menu.07:09
dcalisteThe new calendar from upstream is added to mkcal storage and visible immediately in the calendar app: nice. But coming back in the setting page, it is not there and worst, leaving the page, erase the new calendar entry from the account settings!07:11
dcalisteThis is due to the fact that the page is storing settings on each pop action, and the model is not refreshed when the settings are changed externally…07:11
chriadamaccounts settings overwriting is causing issues elsewhere also07:11
chriadamshould only store delta rather than clobber write everything07:11
chriadamthere is a bug about that internally07:12
dcalisteThe other option would be to update the model (there is a routine for that) on account change.07:12
dcalisteI can propose something in the jolla-setting-account if you think it's worth to include the caldav MR.07:13
dcalisteAnd this setting issue may block it.07:13
chriadamindeed, but IIRC accounts&sso Accounts::Manager only emits change signals if constructed with view for particular service types.  I could be wrong about that, as it's been a while since I looked at that level.07:13
dcalisteI didn't investigate much myself neither, just some random thoughts !07:14
chriadamdcaliste: well, let me have a think.  could be that the problem goes away in the near future if that internal bug I mentioned gets fixed.  aside from that, I don't think this rescan change will get into next release anyway (too much chance for regression) so we have some time to think about how best to address the issue07:14
dcalisteOk, As you want. At the same time, except this setting page issue, the rescan should not trigger regression (we always think that… I know) since it is only adding calendars, not removing anyone that may have disappeared. Also any other error are silently ignored and sync proceed as usual.07:16
dcalisteBut I agree that it's not very nice to say to user: it may detect new calendars… or not ;)07:18
chriadamI'm more worried about keeping the delta as small as possible for this release, as it's already getting massive07:18
dcalisteI understand, you're the maintainer.07:19
dcalisteThe last point about calendar is the sync on change MR.07:20
chriadamoh, I forgot about that one, sorry07:20
chriadamin jolla-calendar right07:20
dcalisteThe current behaviour is quite annoying, even if for account foo the sync on change is disabled, any change in any calendar of this account foo is triggering sync for _every_ other accounts that have sync on change.07:21
chriadamcertainly would be good to get that fix in07:21
dcalisteThe MR is fragile in the fact that getting the account id from notebook id is a sqlite request, so it can hang…07:22
chriadamah, that's right, pvuorela had concern about using mkcal level things here07:22
dcalisteI've tried to follow pvuorela advice and implement it with NemoCalendarNotebbokQuery from nemo-qml-plugin-calendar.07:22
dcalisteIt was nice up to the moment I notice that the .so is for QML only and not exported for compilation on C++ side like for email.07:23
dcalisteIf pvuorela or you think it's required, I can put a worker in synchelper code to do the association account id <-> calendar id.07:24
dcalisteThe other solution is to expose notebook id inside calendar in QML by modifying nemo-qml-plugin-calendar, but I'm quite reluctant to do this because it's not mapping the kcalcore archjitecture.07:25
dcalistesorry, mkcal architecture.07:25
dcalistenotebook doesn't exist in kcalcore…07:25
dcalisteAt the same time, we're just requesting notebook id, it's a very minor sqlite call…07:26
chriadammy personal preference (longer term) would be to have a calendar daemon, which provides API to clients via IPC.  that way threaded issues go away, and we can do proper access control.07:27
chriadambut in the meantime, we're stuck with in-process database file access, and unfortunately sqlite is not concurrent thread nor concurrent process safe07:27
chriadamwell, maybe SELECT queries are, I'd need ot double check that07:28
chriadampvuorela: did you have any comments ^07:28
pvuorelaum, let me see.07:30
dcalisteReading from random articles on the web, concurrent access is possible. But a writing access is locking the DB. So if the caldav plugin is syncing a huge calendar for instance, the request to read the notebook ids may hang.07:32
dcalisteBut how often a scenario with a _very_ long write sequence will happen and _at the same time_ we will trigger this sync on change ? To be perfectly on the safe side, I can definitely delegate this sqlite read from synchelper in a QtConcurrent thread…07:35
chriadamindeed, that seems sensible.  so long as we can excise all of this code cleanly in some utopian future when we have daemonised calendar API or refactored Buteo etc.07:37
pvuorelai started pondering if all buteo sync should be done in nemo-calendar plugin.07:37
pvuorelathere it could use all the data and state in the worker thread.07:37
dcalistepvuorela: that makes sense. This nemo-calendar may become this calendar-daemon we're thinking about. The worker thread should be daemonized first though.07:40
dcalisteMore short term: so I add a QtConcurrent in the calendar MR?07:40
dcalisteLike that, the concurrent read access in sqlite is safe, and the hanging will not be noticed from the UI thread where the code is coming from.07:41
dcalistechriadam: removing later will be easy: just erase everything related to synchelper ;)07:42
pvuorelafor calendar-daemon part i'm not entirely convinced i'm wanting such, but that's a bit different topic :)07:42
chriadamhehe right07:43
chriadamlet's not go down that path now07:44
chriadamquestion is more: is mkcal linkage in jolla-calendar (with QtConcurrent to avoid potential hang) a lesser evil than changing nemo-qml-plugin-calendar to expose account id (which is not something kcalcore is aware of)07:44
pvuorelaor that buteo sync movin.g07:46
dcalisteOr to rephrase: do we have potential other areas where account ids may be needed when dealing with notebooks ?07:46
dcalistePersonnaly, I'm not aware of any other places. So, short term solution: I'll update the calendar app MR later today, adding in the background a fetch of account ids from notebook ids. Do you both, pvuorela and chriadam, agree ?07:50
chriadamsounds good to me07:51
dcalisteThe advantages: strange code is localised in synchelper and easy to remove when a better solution exists. Disadvantages: we may duplicate code by putting something needed elsewhere in that hidden place.07:51
chriadamI think it's the only case, that I can think of at least07:51
chriadamand code-locality is a big plus07:51
chriadamthanks very much for taking initiative there as always dcaliste07:53
dcalisteLast topic: email signature and related issues.07:53
dcalisteI'm still working right now on adding cancellation API to user interaction plugin in secrets.07:53
dcalisteIt may be finished later this week, or not…07:54
dcalisteOn the UI side, do you have any plan to accept MRs in their current state? Or do you prefer to have another verification from jpetrell or pvuorela ?07:55
chriadamI'd really prefer pvuorela or jpetrell to approve those07:55
jpetrellno need for another verification from me07:55
dcalistechriadam: I understand, big implications ;)07:56
dcalistethanks jpetrell!07:56
pvuorelai don't think i had too much code concerns anymore. for most haven't still run the signing properly on device but it seemed isolated anyway now so shouldn't at least harm the common case.07:57
chriadamoh, I see that pvuorela already said the n-q-p-e is ok07:57
jpetrelln-q-p-e :D07:57
chriadamthe jolla-email one still lacks a tick07:57
chriadamand there was an open question about dconf value for autoVerifySignature - was that already resolved?07:58
dcalistechriadam: yes, I've added a config in the email setting.07:58
dcalisteAnd the config is installed only when the email signature stuff is installed.07:58
dcalisteMore cleanly it is coming with the jolla-email-crypto-gnupg package.07:59
dcaliste[mersdk@SailfishSDK sailfish-secrets]$ rpm -qpl ../ui-jolla-email/RPMS/jolla-email-crypto-gnupg-0.4.4-1.armv7hl.rpm08:00
jpetrelldcaliste: there is some new code there, I'll review08:03
jpetrellbut in general for an opt-in feature I think we have done more than enough reviewing :P :)08:04
chriadamjpetrell: you can check comment 18 from JB#42413 for explicit instructions to test08:04
chriadamif you feel so inclined ;-)08:04
jpetrelllet's see, if it turns out to be multi-hour exercise maybe not at this time08:04
dcalistejpetrell ;) Yes, I've added some code on pvuorela's advice to have an option not to check automatically signature on incoming emails.08:05
dcalisteThis would avoid nasty attackers to try to send random data in our ancient GnuPG version and trigger a buffer overflow there.08:05
chriadamindeed.  reminds me...08:06
chriadamneed to ask internally about roadmap for GPLv3 stuff again ;-)08:07
dcalistejpetrell: if everything goes right (which is usually not the case…), you just need to install jolla-email-crypto-gnupg package. It will pull required dependencies at once.08:08
chriadamdcaliste: ok, I guess that about covers everything?  action points for me: 1) check kcalcore MR.  2) check two buteo-caldav MRs, although one of those I consider lower priority currently.  3) check jolla-calendar sync-on-change PR once you update that one.  4) re-test, merge, tag gpg stuff once/if jpetrell approves that jolla-email one.08:08
chriadamdid I miss anything?08:09
dcalisteBut looking at it more closely, I've just noticed that the setting dependency is missing, screwed.08:09
dcalistechriadam: perfectly right, yes.08:09
chriadamgreat :-)08:10
chriadamthanks again for your effort and time08:10
jpetrellchriadam: sounds good08:11
dcalistechriadam: no problem.08:11
dcalisteI'm adding the missing jolla-setting dependency in the spec file right now.08:12
dcalisteGood night Chris. See you.08:12
dcalisteThanks jpetrell for the remarks on the email app MR. I've updated the code accordingly.08:44
jpetrelldcaliste: cheers08:44
jpetrellwill review a bit still later08:44
dcalisteSure, no problem. Thank you. I'll follow the activity in bitbucket.08:45
*** Renault_ is now known as Renault10:39
sb0amazingly, nix works just fine on sailfishos. i can even run funky stuff like FPGA toolchains and rust applications12:11
*** frinring_ is now known as frinring13:17
Almindorjusa: are you here at any time of day?16:06
Almindorhow can you make the SDK/qtcreator "see" header files from pkg-config libraries that were set up by zypper for given targets?16:48
AlmindorI suppose I'd have to copy them over to the sdk include folders on the host16:49
kimmolihttps://sailfishos.org/wiki/Application_SDK_FAQ#How_do_I_add_additional_development_headers_to_the_SailfishOS_target.3F ? this not helping?16:50
Almindorhmm I used sb2/zypper on the machine itself, I wonder if this copies something to the host/sdk folder too16:51
Almindorwill try16:51
Almindornice it has a sync button for this case16:53
Almindorhmm, file is now in my mersdk folder in usr/include but it's still not found by qtCreator, I guess it doesn't really check there by default16:56
Almindorseems /usr/include isn't included by default, adding that to INCLUDEPATH fixes it17:21
JareAlmindor: we're working on a fix, but yes currently the manual usage of the includepath is needed20:26
duncan^sb0 mentioned Nix21:27
duncan^hyes, it works fine21:27
duncan^but locales on sailfish seem slightly odd - programs typically complain that locales aren't set correctly. most programs, even if natively compiled, seem to think I'm using an ANSI locale, even though it's clearly set to en-GB.UTF821:29
duncan^or en_GB.utf8 to be exact.21:29
duncan^I don't know if it's because loads of the stuff from mer is a decade old (screen from 2003, Bash from 2007, gpg2 from 2007...), but a newer bash and screen didn't help.21:30
duncan^for instance, weechat detects the terminal character set as just an ANSI one, or a POSIX one, despite internally suppporting UTF-821:31
duncan^w3m fairs better, and can display accented characters.21:31
duncan^so it's some problem with the way locales are set up, I'm certain. It's not the terminal emulator because ssh'ing in and running a given program doesn't help21:32
duncan^screen -U inherits the craziness, despite that forcing UTF-8 (or, it should)21:32
Almindorspiiroin: any way you could ask jusa to provide more info on the audio sink/swap thing? I tried pinging him here for over a week. I also tried sending to the dev ML but my msg never went through (got the "needs to be reviewed" email but then nothing)21:33
duncan^I even tried qterminal, janky as it is on sailfish, which faired no better21:33
duncan^I"m not sure how to fix locales but it would certainly make the experience using various programs in the terminal more pleasant.21:33
duncan^it's also not an issue with nix, for instance weechat compiled on sailfish is totallyh unhappy too.21:34
duncan^/charset displays ssome ANSI charset for terminal charset, and UTF-8 for th e internal, program charset.21:34
duncan^if I ssh elsewhere, to a system where the locales are fine, I can display weechat running there no problem.21:35
*** SpeedEvil is now known as Guest4579122:14

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