| *** frinring_ is now known as frinring | 00:23 | |
| *** frinring_ is now known as frinring | 01:41 | |
| *** mikkoh_ is now known as mikkoh | 05:40 | |
| *** leinir_ is now known as leinir | 06:45 | |
| dcaliste | Helo chriadam and jpetrell. Sorry to be late once again. My time schedule is a mess with the children holiday season. I should be back to normal on time in September. | 07:22 |
|---|---|---|
| chriadam | no problem ;-) | 07:22 |
| chriadam | I hope you had a good week! | 07:23 |
| dcaliste | Fine, thank you. | 07:24 |
| dcaliste | I've read the review comments of jpetrell on bitbucket. | 07:24 |
| dcaliste | I've addressed most of them, but didn't push back the modifications yet. | 07:24 |
| dcaliste | There are two that requires to think about: | 07:25 |
| dcaliste | - one about the fact that I'm using the name of the plugin to know the capabilities. I need to add capability inquires functions to nemo-qml-plugin-email I think for this. | 07:25 |
| dcaliste | - the second about the naming of the keys. | 07:26 |
| dcaliste | This second is a bit tricky. GnuPG is using fingerprint to identify keys. | 07:26 |
| dcaliste | And users are often using the last 8 characters of the fingerprint (see email signatures of some people using GPG keys). | 07:27 |
| dcaliste | I agree that this is not very user friendly. | 07:27 |
| dcaliste | jpetrell proposed to give a name to the keys. | 07:27 |
| chriadam | the secrets/crypto API originally had programmatic reporting of capabilities, however after long discussion and thought it was removed from the API. basically, it's too difficult to report "properly" for every combination of potential parameters (block modes, paddings, algorithms, custom parameters, etc). | 07:27 |
| chriadam | so my current opinion is that applications (including "system" applications like qmf etc) need to "know" the plugins they attempt to target. | 07:28 |
| chriadam | regarding the "giving a name to the keys" - the keyName in the keyIdentifier is a machine-readable, unique name. it can be used to store a human-readable label, but that is not required. | 07:28 |
| jpetrell | improving naming is minor UX improvement, don't spend too much time on it if the solution becomes increasingly difficult | 07:29 |
| chriadam | you may use filterData or key customParameters to store a human-readable label. | 07:29 |
| dcaliste | Yes, I agree with you, but the association "libgpgme.so" <-> "PGP capability" can be done at the nemo-qml-plugin-email level. | 07:29 |
| chriadam | while it is suboptimal that we don't expose a displayName() in the top level api, that can easily be added (I suggest that it be a simple wrapper around filterData.value("DisplayName") personally) | 07:29 |
| dcaliste | For the human readable label, technically, this could be possible in the current framework: the user defined name (my signing key for instance) can be stored as the key name, while the fingerprint is exposed as the public data of the key. | 07:30 |
| dcaliste | The problem with this solution is how to give the user the choice of naming the keys… | 07:30 |
| chriadam | IMO it should just be stored to the filterData | 07:30 |
| dcaliste | Since they are not imported, but exposed to secret API. | 07:30 |
| dcaliste | jpetrell: ok not to spend too much time, but it's nice to brainstorm a bit together. Ideas may emerge (or not). | 07:32 |
| dcaliste | chriadam, why not use a displayName filter data, indeed. In UI, user may modify key properties like this one easily, while it is still easy to add a displayName() API to Key. The only trouble here is that key listing functions are usually returning Key::Identifier only… | 07:34 |
| chriadam | good point | 07:35 |
| chriadam | we should update the Filter request | 07:36 |
| dcaliste | Which in turn, make my solution fragile also, since the key listing will require an additional query if fingerprint is required but stored in the public data instead of the name. | 07:36 |
| chriadam | so that it returns the filterData for each identifier which has matching filterData to the supplied filter | 07:36 |
| chriadam | hrm, but that has issues too. | 07:37 |
| chriadam | yes, the double-request thing is very unfortunate. | 07:37 |
| dcaliste | It may complexify the API too much for simple listing request. | 07:38 |
| chriadam | in general, I think it not too outlandish to return both identifiers + associated filterData for a list request. however we'd have to be careful how such would be exposed. | 07:39 |
| dcaliste | Maybe, I can open a Github issue about this problem, so we don't forget about it and can allow more time to think about pro and cons of different possibilities. | 07:40 |
| chriadam | it can probably be done in BC manner also (add a Q_INVOKABLE FilterData filterData(const Identifier &ident) const; lookup method to the request-derived class) | 07:40 |
| chriadam | yes, please do that | 07:40 |
| dcaliste | Ok, I'll copy paste some of the discussion here later today about this. | 07:41 |
| dcaliste | Another point about API: | 07:41 |
| dcaliste | last time we discuss about the mail account setting. | 07:41 |
| dcaliste | We decided that one needs to store pluginName (in QMF sense), keyNames and collectionNames. | 07:42 |
| dcaliste | I begun to make the changes for this, but I think we need some more discussion, if possible. | 07:42 |
| chriadam | sure | 07:43 |
| dcaliste | As mentioned above, pluginName is the plugin name for QMF, one cannot put "org.sailfish.crypto.gnupg.openpgp", because this is the plugin name for Secret. | 07:43 |
| dcaliste | When we create a QMF plugin based on secret, called libsecret.so for instance, it's that name that should be stored. | 07:44 |
| dcaliste | Which in turn, add the requirement that "o.s.crypto.gnupg.openpgp" or "o.s.crypto.gnupg.smime" should be stored also. | 07:45 |
| chriadam | I see | 07:45 |
| dcaliste | depending if one wants to use PGP or S/MIME standard to sign. | 07:45 |
| dcaliste | My suggestion is to store all of this in keyNames. | 07:45 |
| chriadam | all? | 07:45 |
| dcaliste | With magic separators. | 07:45 |
| dcaliste | I don't like much magic separators for arbitrary strings, but… | 07:46 |
| chriadam | so, pluginName="libsecret.so", keyNames="o.s.c.gnupg.openpgp:someCollectionName:someKeyName" sort of thing? | 07:46 |
| dcaliste | Exactly. | 07:46 |
| chriadam | one issue is that I don't think we have any specific restrictions on characters which can be used in collection or key names | 07:47 |
| dcaliste | It avoids also to create tuples from separated settings. | 07:47 |
| chriadam | so if a collection name includes the separator character then that messes up the split | 07:47 |
| dcaliste | Yes, I agree. But we can use complex separator like ":plop:plop:" or whatever, it's setting that user don't see anyway. | 07:48 |
| dcaliste | It has the second advantage that it's not imposing the identification used by secret to the QMF account setting API. | 07:49 |
| dcaliste | The disadvantage is of course the risk of collision. | 07:49 |
| dcaliste | That can be mitigated by not saving a setting with a collision and raising an error. | 07:49 |
| chriadam | I agree | 07:51 |
| chriadam | that would need to be checked in both the plugin name and collection name (save) codepaths in the secrets daemon | 07:52 |
| chriadam | unfortunately .. hrm... we can't prevent a plugin from exposing such a collection, I suppose | 07:52 |
| chriadam | well, the alternative is just to use something which is highly unlikely, e.g. ":qmfseparator:" | 07:54 |
| chriadam | and then if some plugin uses that in its name, or in a collection it supports, well, too bad. | 07:55 |
| chriadam | the worst that happens is that attempting to use such a key simply won't work | 07:55 |
| dcaliste | That's exactly my thoughts, yes. | 07:58 |
| chriadam | I wonder how likely it is that a plugin or collection would include pipe "|" | 07:59 |
| chriadam | shrug | 07:59 |
| chriadam | I'm fine with whatever solution you decide on. | 07:59 |
| dcaliste | A single character, yes quite likely, I'm afraid. I prefer the complex separator like :qmfseparator: indeed. | 08:00 |
| dcaliste | Ok, thank you for your opinion. | 08:01 |
| chriadam | thank you for raising this, I had clearly misunderstood the linkage between the qmf-related account settings and the plugin name / key name separation there | 08:03 |
| dcaliste | Me also, I discovered it when trying to implement what we discussed last time ! | 08:03 |
| chriadam | that's the problem with complicated systems - the true underlying requirements sometimes only become apparent during concrete implementation :-/ | 08:04 |
| dcaliste | Not related, I'm going to give a look to the proposed change in caldav buteo handler about the incidence with with missing URI. Will comment later today or tomorrow on the Gitlab MR. | 08:06 |
| chriadam | thanks, it's not so urgent but a second opinion would be good. it's a workaround rather than a fix; I don't know how the "actual" issue occurred... | 08:06 |
| chriadam | i.e. the loss of the remote uri information from the local event | 08:06 |
| chriadam | that's MER#1944 but unrelated to that one I also received MER#1945 the other day. I don't think I'll get a chance to investigate that one any time soon, though, unforutnately. | 08:09 |
| dcaliste | Sorry, was discussing with a colleague. I'm reading #1945 description. | 08:15 |
| dcaliste | Arg, etag not reported will break a lot of current CalDAV handling… | 08:17 |
| dcaliste | No idea now how to handle this. | 08:17 |
| dcaliste | Will try to investigate how it is done elsewhere in Gnome for instance. | 08:18 |
| chriadam | cheers | 08:20 |
| chriadam | no rush :-) | 08:20 |
| chriadam | I have to head home, it's getting late | 08:20 |
| chriadam | thanks for the discussion | 08:20 |
| chriadam | I hope you have a great week :-) | 08:20 |
| dcaliste | Sure, of course. Have a nice evening. | 08:20 |
| dcaliste | jpetrell: some words about yet another unrelated topic: I've continue to try to compile latest Calligra in the way we discussed last time with lbt and pvuorela. | 08:20 |
| dcaliste | All kf5 dependencies are put as a pre-build target in the spec file. | 08:21 |
| dcaliste | I'm trying to cut-down as much as possible dependencies (like removing Network support for instance), as leinir has done when doing the first importation. | 08:22 |
| dcaliste | I will push something to gitlab later this week I think if you want to give a look. | 08:22 |
| leinir | dcaliste: Ooh, a proper KF5? :) That /was/ our original intention when we did the whole single-.so frameworks stuff, so having that'd be really neat :) | 08:27 |
| leinir | Incidentally, it might make sense to just try and use the android build options to create a kf5 build that's sort of... similar in scope to what SailfishOS might want :) | 08:28 |
| dcaliste | leinir: Yes. I'm currently compiling 5.34.0 upstream version because of Qt5.6 in Sailfish, but will switch to something higher when 5.9 is landing. | 08:28 |
| leinir | Nicely :D | 08:28 |
| leinir | Aah right, the android options didn't land until... uhm, recently ;) | 08:28 |
| dcaliste | We discussed Tuesday last week about the way to put this in Mer, you may give a look in the back log if interested (and time available). The current situation is to bundle kf5 parts inside the same calligra spec file. | 08:29 |
| dcaliste | But use git submodule to handle the kf5 subdirs. | 08:29 |
| dcaliste | So one can easily follow upstream (when Qt will be upgraded also). | 08:30 |
| dcaliste | leinir: I will have also some modifications to propose to KDE calligra, mainly in the CMakeList files to allow to build subdirs separately with the right minimal KF5 dependencies. | 08:31 |
| leinir | nods* That's not a bad idea, makes it just sort of... happen :) | 08:32 |
| leinir | Hmm, sure! Phabricator them and we'll take a good, solid look :) | 08:32 |
| dcaliste | Thanks, it will be proposed in the coming days, or weeks, depending when I finish to have something that compiles up to the end! | 08:33 |
| leinir | Great! Look forward to seeing them :) | 08:34 |
| dcaliste | Thank you. I'm also waiting to have my KDE dev account accepted. | 08:36 |
| DarkWhite_ | Hi, does usb otg work on Mouhijoki? | 09:55 |
| leszek | DarkWhite_: depends on the device I would say. It is not working on Jolla 1 afaik though the hardware supports it | 09:57 |
| DarkWhite_ | I tried on Jolla Tablet and Xperia X and it doesn't work | 10:01 |
| DarkWhite_ | maybe it is related to new mount path change? | 10:02 |
| leszek | what did you try exactly? | 10:02 |
| leszek | plugging in a keyboard for example works nice without any issues | 10:02 |
| leszek | if you want to mount usb devices you need to install https://openrepos.net/content/ferlanero/usb-stick-utils-automount-exfat-support to have them automounted. Otherwise you need to mount them on your own | 10:03 |
| DarkWhite_ | usb stick and i have that package installed | 10:04 |
| r0kk3rz | they did change the mount points recently | 10:05 |
| r0kk3rz | so that package could be broke | 10:05 |
| DarkWhite_ | i suspect it is broken for now | 10:07 |
| x2s | Hi. What does it mean, when the status led on my XperiaX is glimming blue? It shuts off, when I switch on the screen. There's no status unread status message | 10:12 |
| spiiroin | x2s: color is in the eye of the observer etc... could be charging indicator that is supposed to be white | 10:20 |
| Mister_Magister | spiiroin: hiiii | 10:20 |
| spiiroin | Mister_Magister: hi to you too | 10:22 |
| Mister_Magister | spiiroin: hows life going | 10:22 |
| Mister_Magister | not overworking at jolla? xD | 10:22 |
| * spiiroin is in middle of irc-meeting elsewhere ... | 10:23 | |
| Mister_Magister | ohhh | 10:23 |
| x2s | spiiroin: possible, but no charger connected ;) | 10:35 |
| spiiroin | x2s: well, on the other hand there is suspected & unresolved bug about having that led pattern on without charger ... https://together.jolla.com/question/169321/xperia-x-white-led-stuck-on-after-charging/ | 10:45 |
| x2s | Ah | 10:47 |
| x2s | I suspected it might be a bug | 10:47 |
| x2s | One of those nasty bugs you hunt for years just to figure out there's a typing error somewhere. :D | 10:50 |
| r0kk3rz | how blue is the blue led | 11:24 |
| x2s | pretty blue, but not very bright | 11:31 |
| x2s | dimmed down much | 11:32 |
| r0kk3rz | yeah sounds like the actual blue led, not a slightly blueish white then | 11:34 |
| x2s | If I had another phone I could make a picture... ;) | 11:35 |
| r0kk3rz | the actual blue led is a fairly deep unmistakable blue anyway | 11:36 |
| r0kk3rz | same as fastboot mode led | 11:36 |
| x2s | Since white leds are just blue leds with a phosphorus filter on them, it could be some white in there, because that filter doesn't work so great when dimmed down much. But it's blue like the charging indication, so I guess it's the same bug spiiroin mentioned | 11:38 |
| spiiroin | x2s r0kk3rz ... IIRC xperia x has non-uniform max brightness for r, g, and b led controls. not sure if it is meant to keep colors more true, or is it causing distortions | 12:56 |
| spiiroin | if it is latter, then it might be more prominent when led brightness is lower (due to als / whatnot) | 12:57 |
| elros1 | Anybody experienced fingerterm random hang when opening new window (QProcess::startDetached)? I would like to get some usefull backtrace of this hangs. Could somebody point me how to do this with gdb | 14:52 |
| elros1 | Opening several windows very fast usually triggers it | 14:53 |
| elros1 | pvuorela: ^ | 15:00 |
| pvuorela | elros1: if you get it hung, you can do gdb -p <pid> | 15:01 |
| pvuorela | "thread apply all bt" | 15:01 |
| elros1 | pvuorela: thanks, backtrace: https://pastebin.com/qX8w5V2y | 15:14 |
| pvuorela | elros1: cut at the bottom? | 15:23 |
| elros1 | pvuorela: ah sorry: https://pastebin.com/xmb4hK9R | 15:30 |
| pvuorela | elros1: thanks. the last one looks interesting. | 15:31 |
| pvuorela | elros1: there have been some fixes in qt for qprocess and suppose it's possible new updates will fix the hang. | 15:38 |
| elros1 | pvuorela: you mean 5.9? so I should remove this commit from pull request? | 15:43 |
| pvuorela | elros1: yea, in 5.9 also. there is qt update proceeding and would be interested if the hang happens with that. if the hang is a rarer one, it could maybe wait until the update too? | 15:44 |
| pvuorela | elros1: or if you see it important enough to fix now, should at least have some comment that qt bug is being worked around. | 15:46 |
| pvuorela | but i need to get going now. | 15:46 |
| elros1 | nobody ever reported it so it's not that important, I can wait | 15:47 |
| *** leinir_ is now known as leinir | 16:43 | |
| *** flx_ is now known as flux | 18:42 | |
| *** kimmoli_ is now known as kimmoli2 | 20:19 | |
| *** TMavica_ is now known as TMavica | 20:19 | |
| *** kimmoli2 is now known as kimmoli | 20:19 | |
| *** BitEvil is now known as speedevil | 20:42 | |
| keithzg[m] | Hmm is there any sort of keyboard shortcut for dismissing the lock screen? | 23:08 |
| *** feodoran is now known as Guest95073 | 23:54 | |
| *** feodoran_ is now known as feodoran | 23:54 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!