| *** zbenjamin is now known as Guest83487 | 01:13 | |
| *** zbenjamin_ is now known as zbenjamin | 01:13 | |
| sb0 | FYI, the bootloader in my H4133 phone incorrectly reports the model number as H3113, and this breaks the flashing script as it is | 03:32 |
|---|---|---|
| sb0 | sailfishos otherwise works correctly on that phone | 03:33 |
| r0kk3rz | did you ever put on lineageoos? | 04:09 |
| sb0 | yes | 04:21 |
| r0kk3rz | that could have been what did it | 04:21 |
| sb0 | so, lineageos modifies the bootloader? | 04:22 |
| r0kk3rz | not sure, ive only heard of that happening on one other device, and it seemed like lineageos did it | 04:23 |
| dcaliste | Hello chriadam and jpetrell. I hope you had a pleasant vacation time, Chris. | 06:48 |
| jpetrell | dcaliste: hi :) | 06:49 |
| chriadam | dcaliste: hi! yes, I did thank you. I hope your easter break was nice also | 06:49 |
| dcaliste | Fine 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 |
| chriadam | great | 06:51 |
| chriadam | I saw some PRs but haven't yet had a chance to look at those ones | 06:51 |
| dcaliste | But 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 |
| dcaliste | chriadam: 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 |
| chriadam | what is the effect? every sync cycle detects a remotely-modified? | 06:53 |
| dcaliste | This is this MR: https://git.merproject.org/mer-core/kcalcore/merge_requests/7 | 06:53 |
| dcaliste | No it is detecting a local modification. | 06:54 |
| dcaliste | The 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 |
| dcaliste | I've explained everything in the MR. | 06:56 |
| chriadam | did 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 |
| chriadam | probably doesn't affect us since they did some akonadi-based refactoring at some point, and we don't use akonadi etc | 06:56 |
| chriadam | but thought I'd mention it. | 06:57 |
| dcaliste | Nice if Kcalkore is developped again. | 06:57 |
| chriadam | that 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 |
| chriadam | thanks for that | 06:58 |
| dcaliste | Good, thank you. | 06:58 |
| dcaliste | The MR in caldav plugin is much more ambitious: https://git.sailfishos.org/mer-core/buteo-sync-plugin-caldav/merge_requests/42 | 07:00 |
| dcaliste | There are minor bug corrections for specific corner cases, but also a lot of refactoring. | 07:01 |
| dcaliste | Do you prefer several small MRs, or you can review each commits of the MR? | 07:01 |
| chriadam | I can review the commits | 07:02 |
| chriadam | no problem | 07:03 |
| chriadam | lots of work there | 07:05 |
| chriadam | thanks for that | 07:06 |
| chriadam | I can't promise when I will get a chance to look at those | 07:06 |
| chriadam | but hopefully later this week | 07:06 |
| chriadam | on the gpg signature side of things, i don't think jpetrell or pvuorela had a chance to review those further while I was away unfortunately | 07:06 |
| chriadam | I'll try to progress those and get them merged/tagged this week or next week. | 07:06 |
| dcaliste | I 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 |
| dcaliste | There is another MR: https://git.sailfishos.org/mer-core/buteo-sync-plugin-caldav/merge_requests/43 | 07:07 |
| dcaliste | This one is orthogonal to the previous and is implementing a long lasting request in TJC about the ability to rescan the calendars. | 07:08 |
| chriadam | ah, instead of merely on account creation | 07:08 |
| chriadam | right | 07:08 |
| dcaliste | It is finally quite easy to add a propfind request at the beginning of each sync cycle. | 07:08 |
| dcaliste | The 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 |
| dcaliste | The 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 |
| dcaliste | This 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 |
| chriadam | accounts settings overwriting is causing issues elsewhere also | 07:11 |
| chriadam | should only store delta rather than clobber write everything | 07:11 |
| chriadam | there is a bug about that internally | 07:12 |
| dcaliste | The other option would be to update the model (there is a routine for that) on account change. | 07:12 |
| dcaliste | I can propose something in the jolla-setting-account if you think it's worth to include the caldav MR. | 07:13 |
| dcaliste | And this setting issue may block it. | 07:13 |
| chriadam | indeed, 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 |
| dcaliste | I didn't investigate much myself neither, just some random thoughts ! | 07:14 |
| chriadam | dcaliste: 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 issue | 07:14 |
| dcaliste | Ok, 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 |
| chriadam | true | 07:17 |
| dcaliste | But I agree that it's not very nice to say to user: it may detect new calendars… or not ;) | 07:18 |
| chriadam | I'm more worried about keeping the delta as small as possible for this release, as it's already getting massive | 07:18 |
| dcaliste | I understand, you're the maintainer. | 07:19 |
| dcaliste | The last point about calendar is the sync on change MR. | 07:20 |
| chriadam | oh, I forgot about that one, sorry | 07:20 |
| chriadam | in jolla-calendar right | 07:20 |
| dcaliste | The 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 |
| chriadam | yes | 07:21 |
| chriadam | certainly would be good to get that fix in | 07:21 |
| dcaliste | The MR is fragile in the fact that getting the account id from notebook id is a sqlite request, so it can hang… | 07:22 |
| chriadam | ah, that's right, pvuorela had concern about using mkcal level things here | 07:22 |
| dcaliste | I've tried to follow pvuorela advice and implement it with NemoCalendarNotebbokQuery from nemo-qml-plugin-calendar. | 07:22 |
| dcaliste | It 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 |
| dcaliste | If 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 |
| dcaliste | The 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 |
| dcaliste | sorry, mkcal architecture. | 07:25 |
| dcaliste | notebook doesn't exist in kcalcore… | 07:25 |
| dcaliste | At the same time, we're just requesting notebook id, it's a very minor sqlite call… | 07:26 |
| chriadam | my 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 |
| chriadam | but in the meantime, we're stuck with in-process database file access, and unfortunately sqlite is not concurrent thread nor concurrent process safe | 07:27 |
| chriadam | well, maybe SELECT queries are, I'd need ot double check that | 07:28 |
| chriadam | pvuorela: did you have any comments ^ | 07:28 |
| pvuorela | um, let me see. | 07:30 |
| dcaliste | Reading 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 |
| dcaliste | But 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 |
| chriadam | indeed, 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 |
| pvuorela | i started pondering if all buteo sync should be done in nemo-calendar plugin. | 07:37 |
| pvuorela | there it could use all the data and state in the worker thread. | 07:37 |
| dcaliste | pvuorela: 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 |
| dcaliste | More short term: so I add a QtConcurrent in the calendar MR? | 07:40 |
| dcaliste | Like 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 |
| dcaliste | chriadam: removing later will be easy: just erase everything related to synchelper ;) | 07:42 |
| chriadam | indeed | 07:42 |
| pvuorela | for calendar-daemon part i'm not entirely convinced i'm wanting such, but that's a bit different topic :) | 07:42 |
| chriadam | hehe right | 07:43 |
| chriadam | let's not go down that path now | 07:44 |
| chriadam | question 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 |
| pvuorela | or that buteo sync movin.g | 07:46 |
| dcaliste | Or to rephrase: do we have potential other areas where account ids may be needed when dealing with notebooks ? | 07:46 |
| dcaliste | Personnaly, 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 |
| chriadam | sounds good to me | 07:51 |
| dcaliste | The 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 |
| chriadam | I think it's the only case, that I can think of at least | 07:51 |
| chriadam | and code-locality is a big plus | 07:51 |
| chriadam | thanks very much for taking initiative there as always dcaliste | 07:53 |
| dcaliste | Last topic: email signature and related issues. | 07:53 |
| dcaliste | I'm still working right now on adding cancellation API to user interaction plugin in secrets. | 07:53 |
| dcaliste | It may be finished later this week, or not… | 07:54 |
| dcaliste | On 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 |
| chriadam | I'd really prefer pvuorela or jpetrell to approve those | 07:55 |
| jpetrell | no need for another verification from me | 07:55 |
| dcaliste | chriadam: I understand, big implications ;) | 07:56 |
| dcaliste | thanks jpetrell! | 07:56 |
| pvuorela | i 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 |
| chriadam | oh, I see that pvuorela already said the n-q-p-e is ok | 07:57 |
| jpetrell | n-q-p-e :D | 07:57 |
| chriadam | the jolla-email one still lacks a tick | 07:57 |
| chriadam | and there was an open question about dconf value for autoVerifySignature - was that already resolved? | 07:58 |
| dcaliste | chriadam: yes, I've added a config in the email setting. | 07:58 |
| dcaliste | And the config is installed only when the email signature stuff is installed. | 07:58 |
| dcaliste | More 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.rpm | 08:00 |
| dcaliste | /usr/share/jolla-email/pages/PublicKeyAgent.qml | 08:00 |
| dcaliste | /usr/share/jolla-email/pages/SignatureItem.qml | 08:00 |
| dcaliste | /usr/share/jolla-settings/pages/jolla-email/crypto.qml | 08:00 |
| jpetrell | dcaliste: there is some new code there, I'll review | 08:03 |
| jpetrell | but in general for an opt-in feature I think we have done more than enough reviewing :P :) | 08:04 |
| chriadam | jpetrell: you can check comment 18 from JB#42413 for explicit instructions to test | 08:04 |
| chriadam | if you feel so inclined ;-) | 08:04 |
| jpetrell | cool | 08:04 |
| jpetrell | let's see, if it turns out to be multi-hour exercise maybe not at this time | 08:04 |
| dcaliste | jpetrell ;) Yes, I've added some code on pvuorela's advice to have an option not to check automatically signature on incoming emails. | 08:05 |
| dcaliste | This would avoid nasty attackers to try to send random data in our ancient GnuPG version and trigger a buffer overflow there. | 08:05 |
| chriadam | indeed. reminds me... | 08:06 |
| chriadam | need to ask internally about roadmap for GPLv3 stuff again ;-) | 08:07 |
| dcaliste | jpetrell: 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 |
| chriadam | dcaliste: 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 |
| chriadam | did I miss anything? | 08:09 |
| dcaliste | But looking at it more closely, I've just noticed that the setting dependency is missing, screwed. | 08:09 |
| dcaliste | chriadam: perfectly right, yes. | 08:09 |
| chriadam | great :-) | 08:10 |
| chriadam | thanks again for your effort and time | 08:10 |
| jpetrell | chriadam: sounds good | 08:11 |
| dcaliste | chriadam: no problem. | 08:11 |
| chriadam | gnight! | 08:12 |
| dcaliste | I'm adding the missing jolla-setting dependency in the spec file right now. | 08:12 |
| dcaliste | Good night Chris. See you. | 08:12 |
| dcaliste | Thanks jpetrell for the remarks on the email app MR. I've updated the code accordingly. | 08:44 |
| jpetrell | dcaliste: cheers | 08:44 |
| jpetrell | will review a bit still later | 08:44 |
| dcaliste | Sure, no problem. Thank you. I'll follow the activity in bitbucket. | 08:45 |
| *** Renault_ is now known as Renault | 10:39 | |
| sb0 | amazingly, nix works just fine on sailfishos. i can even run funky stuff like FPGA toolchains and rust applications | 12:11 |
| *** frinring_ is now known as frinring | 13:17 | |
| Almindor | jusa: are you here at any time of day? | 16:06 |
| Almindor | how can you make the SDK/qtcreator "see" header files from pkg-config libraries that were set up by zypper for given targets? | 16:48 |
| Almindor | I suppose I'd have to copy them over to the sdk include folders on the host | 16:49 |
| kimmoli | https://sailfishos.org/wiki/Application_SDK_FAQ#How_do_I_add_additional_development_headers_to_the_SailfishOS_target.3F ? this not helping? | 16:50 |
| Almindor | hmm I used sb2/zypper on the machine itself, I wonder if this copies something to the host/sdk folder too | 16:51 |
| Almindor | will try | 16:51 |
| Almindor | nice it has a sync button for this case | 16:53 |
| Almindor | hmm, 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 default | 16:56 |
| Almindor | seems /usr/include isn't included by default, adding that to INCLUDEPATH fixes it | 17:21 |
| Jare | Almindor: we're working on a fix, but yes currently the manual usage of the includepath is needed | 20:26 |
| duncan^ | sb0 mentioned Nix | 21:27 |
| duncan^ | hyes, it works fine | 21: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.UTF8 | 21: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-8 | 21: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 help | 21:32 |
| duncan^ | screen -U inherits the craziness, despite that forcing UTF-8 (or, it should) | 21:32 |
| Almindor | spiiroin: 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 better | 21: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 Guest45791 | 22:14 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!