Tuesday, 2018-08-21

*** frinring_ is now known as frinring00:23
*** frinring_ is now known as frinring01:41
*** mikkoh_ is now known as mikkoh05:40
*** leinir_ is now known as leinir06:45
dcalisteHelo 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
chriadamno problem ;-)07:22
chriadamI hope you had a good week!07:23
dcalisteFine, thank you.07:24
dcalisteI've read the review comments of jpetrell on bitbucket.07:24
dcalisteI've addressed most of them, but didn't push back the modifications yet.07:24
dcalisteThere 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
dcalisteThis second is a bit tricky. GnuPG is using fingerprint to identify keys.07:26
dcalisteAnd users are often using the last 8 characters of the fingerprint (see email signatures of some people using GPG keys).07:27
dcalisteI agree that this is not very user friendly.07:27
dcalistejpetrell proposed to give a name to the keys.07:27
chriadamthe 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
chriadamso my current opinion is that applications (including "system" applications like qmf etc) need to "know" the plugins they attempt to target.07:28
chriadamregarding 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
jpetrellimproving naming is minor UX improvement, don't spend too much time on it if the solution becomes increasingly difficult07:29
chriadamyou may use filterData or key customParameters to store a human-readable label.07:29
dcalisteYes, I agree with you, but the association "libgpgme.so" <-> "PGP capability" can be done at the nemo-qml-plugin-email level.07:29
chriadamwhile 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
dcalisteFor 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
dcalisteThe problem with this solution is how to give the user the choice of naming the keys…07:30
chriadamIMO it should just be stored to the filterData07:30
dcalisteSince they are not imported, but exposed to secret API.07:30
dcalistejpetrell: ok not to spend too much time, but it's nice to brainstorm a bit together. Ideas may emerge (or not).07:32
dcalistechriadam, 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
chriadamgood point07:35
chriadamwe should update the Filter request07:36
dcalisteWhich 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
chriadamso that it returns the filterData for each identifier which has matching filterData to the supplied filter07:36
chriadamhrm, but that has issues too.07:37
chriadamyes, the double-request thing is very unfortunate.07:37
dcalisteIt may complexify the API too much for simple listing request.07:38
chriadamin 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
dcalisteMaybe, 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
chriadamit 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
chriadamyes, please do that07:40
dcalisteOk, I'll copy paste some of the discussion here later today about this.07:41
dcalisteAnother point about API:07:41
dcalistelast time we discuss about the mail account setting.07:41
dcalisteWe decided that one needs to store pluginName (in QMF sense), keyNames and collectionNames.07:42
dcalisteI begun to make the changes for this, but I think we need some more discussion, if possible.07:42
dcalisteAs 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
dcalisteWhen we create a QMF plugin based on secret, called libsecret.so for instance, it's that name that should be stored.07:44
dcalisteWhich in turn, add the requirement that "o.s.crypto.gnupg.openpgp" or "o.s.crypto.gnupg.smime" should be stored also.07:45
chriadamI see07:45
dcalistedepending if one wants to use PGP or S/MIME standard to sign.07:45
dcalisteMy suggestion is to store all of this in keyNames.07:45
dcalisteWith magic separators.07:45
dcalisteI don't like much magic separators for arbitrary strings, but…07:46
chriadamso, pluginName="libsecret.so", keyNames="o.s.c.gnupg.openpgp:someCollectionName:someKeyName" sort of thing?07:46
chriadamone issue is that I don't think we have any specific restrictions on characters which can be used in collection or key names07:47
dcalisteIt avoids also to create tuples from separated settings.07:47
chriadamso if a collection name includes the separator character then that messes up the split07:47
dcalisteYes, I agree. But we can use complex separator like ":plop:plop:" or whatever, it's setting that user don't see anyway.07:48
dcalisteIt has the second advantage that it's not imposing the identification used by secret to the QMF account setting API.07:49
dcalisteThe disadvantage is of course the risk of collision.07:49
dcalisteThat can be mitigated by not saving a setting with a collision and raising an error.07:49
chriadamI agree07:51
chriadamthat would need to be checked in both the plugin name and collection name (save) codepaths in the secrets daemon07:52
chriadamunfortunately .. hrm... we can't prevent a plugin from exposing such a collection, I suppose07:52
chriadamwell, the alternative is just to use something which is highly unlikely, e.g. ":qmfseparator:"07:54
chriadamand then if some plugin uses that in its name, or in a collection it supports, well, too bad.07:55
chriadamthe worst that happens is that attempting to use such a key simply won't work07:55
dcalisteThat's exactly my thoughts, yes.07:58
chriadamI wonder how likely it is that a plugin or collection would include pipe "|"07:59
chriadamI'm fine with whatever solution you decide on.07:59
dcalisteA single character, yes quite likely, I'm afraid. I prefer the complex separator like :qmfseparator: indeed.08:00
dcalisteOk, thank you for your opinion.08:01
chriadamthank you for raising this, I had clearly misunderstood the linkage between the qmf-related account settings and the plugin name / key name separation there08:03
dcalisteMe also, I discovered it when trying to implement what we discussed last time !08:03
chriadamthat's the problem with complicated systems - the true underlying requirements sometimes only become apparent during concrete implementation :-/08:04
dcalisteNot 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
chriadamthanks, 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
chriadami.e. the loss of the remote uri information from the local event08:06
chriadamthat'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
dcalisteSorry, was discussing with a colleague. I'm reading #1945 description.08:15
dcalisteArg, etag not reported will break a lot of current CalDAV handling…08:17
dcalisteNo idea now how to handle this.08:17
dcalisteWill try to investigate how it is done elsewhere in Gnome for instance.08:18
chriadamno rush :-)08:20
chriadamI have to head home, it's getting late08:20
chriadamthanks for the discussion08:20
chriadamI hope you have a great week :-)08:20
dcalisteSure, of course. Have a nice evening.08:20
dcalistejpetrell: 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
dcalisteAll kf5 dependencies are put as a pre-build target in the spec file.08:21
dcalisteI'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
dcalisteI will push something to gitlab later this week I think if you want to give a look.08:22
leinirdcaliste: 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
leinirIncidentally, 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
dcalisteleinir: 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
leinirNicely :D08:28
leinirAah right, the android options didn't land until... uhm, recently ;)08:28
dcalisteWe 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
dcalisteBut use git submodule to handle the kf5 subdirs.08:29
dcalisteSo one can easily follow upstream (when Qt will be upgraded also).08:30
dcalisteleinir: 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
leinirnods* That's not a bad idea, makes it just sort of... happen :)08:32
leinirHmm, sure! Phabricator them and we'll take a good, solid look :)08:32
dcalisteThanks, 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
leinirGreat! Look forward to seeing them :)08:34
dcalisteThank you. I'm also waiting to have my KDE dev account accepted.08:36
DarkWhite_Hi, does usb otg work on Mouhijoki?09:55
leszekDarkWhite_: depends on the device I would say. It is not working on Jolla 1 afaik though the hardware supports it09:57
DarkWhite_I tried on Jolla Tablet and Xperia X and it doesn't work10:01
DarkWhite_maybe it is related to new mount path change?10:02
leszekwhat did you try exactly?10:02
leszekplugging in a keyboard for example works nice without any issues10:02
leszekif 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 own10:03
DarkWhite_usb stick and i have that package installed10:04
r0kk3rzthey did change the mount points recently10:05
r0kk3rzso that package could be broke10:05
DarkWhite_i suspect it is broken for now10:07
x2sHi. 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 message10:12
spiiroinx2s: color is in the eye of the observer etc... could be charging indicator that is supposed to be white10:20
Mister_Magisterspiiroin: hiiii10:20
spiiroinMister_Magister: hi to you too10:22
Mister_Magisterspiiroin: hows life going10:22
Mister_Magisternot overworking at jolla? xD10:22
* spiiroin is in middle of irc-meeting elsewhere ...10:23
x2sspiiroin: possible, but no charger connected ;)10:35
spiiroinx2s: 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
x2sI suspected it might be a bug10:47
x2sOne of those nasty bugs you hunt for years just to figure out there's a typing error somewhere. :D10:50
r0kk3rzhow blue is the blue led11:24
x2spretty blue, but not very bright11:31
x2sdimmed down much11:32
r0kk3rzyeah sounds like the actual blue led, not a slightly blueish white then11:34
x2sIf I had another phone I could make a picture... ;)11:35
r0kk3rzthe actual blue led is a fairly deep unmistakable blue anyway11:36
r0kk3rzsame as fastboot mode led11:36
x2sSince 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 mentioned11:38
spiiroinx2s 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 distortions12:56
spiiroinif it is latter, then it might be more prominent when led brightness is lower (due to als / whatnot)12:57
elros1Anybody 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 gdb14:52
elros1Opening several windows very fast usually triggers it14:53
elros1pvuorela: ^15:00
pvuorelaelros1: if you get it hung, you can do gdb -p <pid>15:01
pvuorela"thread apply all bt"15:01
elros1pvuorela: thanks, backtrace: https://pastebin.com/qX8w5V2y15:14
pvuorelaelros1: cut at the bottom?15:23
elros1pvuorela: ah sorry: https://pastebin.com/xmb4hK9R15:30
pvuorelaelros1: thanks. the last one looks interesting.15:31
pvuorelaelros1: there have been some fixes in qt for qprocess and suppose it's possible new updates will fix the hang.15:38
elros1pvuorela: you mean 5.9? so I should remove this commit from pull request?15:43
pvuorelaelros1: 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
pvuorelaelros1: 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
pvuorelabut i need to get going now.15:46
elros1nobody ever reported it so it's not that important, I can wait15:47
*** leinir_ is now known as leinir16:43
*** flx_ is now known as flux18:42
*** kimmoli_ is now known as kimmoli220:19
*** TMavica_ is now known as TMavica20:19
*** kimmoli2 is now known as kimmoli20:19
*** BitEvil is now known as speedevil20:42
keithzg[m]Hmm is there any sort of keyboard shortcut for dismissing the lock screen?23:08
*** feodoran is now known as Guest9507323:54
*** feodoran_ is now known as feodoran23:54

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