| *** frinring_ is now known as frinring | 01:01 | |
| rydare | kimmoli: you have a oneplus x right? have you had any issues with inaccurate battery percentages? | 01:26 |
|---|---|---|
| rydare | I'm seeing a post form 2016-03-20, about battery reading 100% for a day. I think that's what i'm experiencing | 01:34 |
| rydare | it went down to 99% | 01:39 |
| rydare | so maybe it is working? | 01:39 |
| rydare | had the same issue the other day, was at 100 until it suddenly went to 49% | 01:40 |
| anuj | exit | 04:06 |
| kimmoli | rydare: yes, that bug is there | 04:23 |
| kimmoli | i thgouht i fixed it, but not completely. the kernel bms tries to smooth that value, and the logic is kinda complicated | 04:25 |
| kimmoli | so it gets stuck in 99/100% or just at 100%. | 04:25 |
| kimmoli | plug in charger for few secs, and it should normalize slowly. | 04:25 |
| dcaliste | Hello chriadam, jpetrell, sorry to be that late today. | 07:26 |
| chriadam | dcaliste: hi, no problem | 07:29 |
| dcaliste | I don't know if jpetrell had time to test the full stack. Anyway, in the meantime, we may resume our implementation detail discussion if you agree. | 07:30 |
| chriadam | certainly | 07:31 |
| dcaliste | ok, it's about the email composition. | 07:32 |
| dcaliste | PGP (or S/MIME) are attached to an email. It's not a technical constrain, it's just metadata. | 07:32 |
| dcaliste | So, in the composer, the UI should propose the user to sign the outgoing mail with the key associated to the email address. | 07:33 |
| dcaliste | One can use FindSecretRequest to do this, but it requires to instanciate a SecretManager and a Request at each time the composer is opened. | 07:34 |
| dcaliste | IMHO it's a bit too much for most of the time, since there may be no PGP key associated to this address. | 07:34 |
| dcaliste | The idea (used in Claws mail also), is to define a setting where we say that such email address should be proposed to be signed with such key. | 07:35 |
| chriadam | We could instantiate a SecretManager (singleton or otherwise) in the email application always, and then only perform the request when needed | 07:36 |
| dcaliste | In Sailfish, such a setting will be an Account setting. So I've modified QMF to save and restore such setting for a QEmailAccount. | 07:36 |
| dcaliste | The Composer is a component that is not always used in the context of the email application, I think. | 07:37 |
| chriadam | true. | 07:37 |
| chriadam | I mean, using an account setting makes sense also | 07:37 |
| chriadam | (assuming that you only ever sign emails sent from one particular email account, with one specific key. is that a true assumption?) | 07:38 |
| dcaliste | I've created 3 account settings, crypto/enabled (bool), crypto/ids (string array, list of fingerprint to be used to sign, usually only one), crypto/type (string, the protocol to be used). | 07:38 |
| dcaliste | The same key can be used for several email address. | 07:39 |
| dcaliste | (for PGP). | 07:39 |
| dcaliste | There can be several email addresses attached to a single key. | 07:39 |
| dcaliste | But normally, you should have only one key for a given email address. | 07:40 |
| dcaliste | But technically, it's not a constrain… | 07:40 |
| chriadam | when you say "list of fingerprint to be used to sign" is that basically a Secrets::Identifier ? or is that specifically fingerprint in the pgp sense? | 07:41 |
| dcaliste | I've decided that they are the same. | 07:41 |
| dcaliste | I'm using the PGP fingerprint as the key identifier name in Secret. | 07:42 |
| dcaliste | This is also a debatable choice ;) | 07:42 |
| chriadam | well I more meant: does it include plugin+collectionName info | 07:43 |
| dcaliste | No. identifier.name() == fingerprint, identifier.collectionName() == user ID (allowing multi key for a given user), and identifier.storagePlugin() == PGP or S/MIME. | 07:45 |
| dcaliste | By the way, the setting crypto/type contains the storagePlugin name. | 07:45 |
| dcaliste | This will allow to be able to use several concurrent plugin for the same task if one wants to. | 07:46 |
| chriadam | ah, ok - so the email app doesn't have to infer the pluginName or collectionName when trying to "build" the correct identifier for the key? e.g. it would do something like: pluginName = value("crypto/type"), collectionName = (email address), keyName = value("crypto/ids").first() | 07:47 |
| dcaliste | For instance, I can set crypto/ids = ["ABCDEF"], crypto/type = "libgpgme.so" (name of the PGP GpgMe based plugin in QMF), or later I can set crypto/type = "libsailfishsecret.so". | 07:47 |
| dcaliste | Well, currently the composer is not using Secret at all. | 07:47 |
| chriadam | what does the signing? just qmf? | 07:47 |
| dcaliste | It is using the nemo-qml-plugin-email API. | 07:47 |
| dcaliste | Which in turn is using a plugin in QMF. | 07:48 |
| dcaliste | Which appears to be using gpgme directly. For the moment. | 07:48 |
| dcaliste | But the email app is using a plugin agnostic API. | 07:48 |
| dcaliste | (well in fact the plugin choice is hidden behind the crypto/type setting. | 07:49 |
| dcaliste | ) | 07:49 |
| chriadam | right, I see | 07:50 |
| chriadam | that's fine | 07:50 |
| chriadam | in the future, we can change qmf (or whatever) to call sailfish-secrets instead of gpgme when performing the signing | 07:51 |
| pvuorela | btw, somewhat related, i'm now rebasing qmf against qt master. finally. | 07:51 |
| chriadam | my main concern with that is: eventually, that component will need "enough information" to appropriately construct a key identifier | 07:51 |
| chriadam | (in the sailfish-secrets sense) --> which needs pluginName + collectionName + keyName. seems like pluginName + keyName are definitely covered, just not 100% sure about collectionName here. | 07:52 |
| dcaliste | pvuorela : amazing. I've looked into both history and it's a total mess, not same ancestor, mixed commits… | 07:52 |
| dcaliste | chriadam: you're concerns are right. | 07:52 |
| pvuorela | dcaliste: yep, hasn't been exactly pleasant, but i have now something, haven't yet compiled it though :) | 07:53 |
| dcaliste | I've not think in advance enough and didn't anticipate the collectionName issue when switching to secret API. | 07:53 |
| dcaliste | pvuorela, congratulation I didn't dare to start it ! | 07:54 |
| pvuorela | dcaliste: you had a bunch of commits on mer side. if you could create upstream PRs at some point it would decrease the delta. | 07:54 |
| dcaliste | pvuorela, sure. I've already created a Qt account last week for this but was stopped by the huge task of finding ancestors, identical commit to rebase on… | 07:55 |
| dcaliste | Should I rebase my commits on upstream master directly ? | 07:55 |
| chriadam | (that is what Michael Nosov did, so I believe so - but will let Pekka confirm or deny that) | 07:56 |
| dcaliste | chriadam, your suggestion to use the email as collection name instead of the full PGP id (like "John Doe (at home) <john.doe@home.org") makes sense. | 07:56 |
| dcaliste | It's less nice in the UI when listing the keys though… | 07:57 |
| pvuorela | dcaliste: yea. to master directly. i'm hoping of getting this somewhat working so i could create a PR, wip or not, and you can perhaps even just pick your things from there. | 07:57 |
| dcaliste | pvuorela, ok I'll rebase my various commits in mer into upstream and submit PR there. Will do within three weeks I think. | 07:58 |
| pvuorela | dcaliste: thanks! | 08:00 |
| dcaliste | chriadam, so to go back to our signing business, I've added a combobox in account setting UI which is based on a FindSecretRequest() and list the keys associated to the account email address that has the signing capability. | 08:00 |
| dcaliste | This combo has always a "no sign please" entry in addition. | 08:01 |
| chriadam | so the user selects the "main" key they wish to use to sign emails with, at account creation time (or, account modify time..) | 08:02 |
| dcaliste | Currently, when changed it set the following settings : crypto/sign (true if a key exists and is selected, false otherwise), crypto/ids (the identifier.name()) and crypto/type (hardcoded to libgpgme.so for the moment). | 08:03 |
| chriadam | I would suggest making the account settings symmetric with the Key::Identifier api in that case, e.g. crypto/pluginNames=[], crypto/collectionNames=[], crypto/keyNames=[]. length of each array must be identical, as they're tuples. | 08:04 |
| dcaliste | Well, for each account they can select the kay they would like to use to sign by default. | 08:04 |
| dcaliste | Ok, I can symmetrise the naming conventions. | 08:05 |
| dcaliste | But I'm a bit concened by the fact that PGP is not exactly 1:1 with secret. | 08:05 |
| chriadam | it is problematic :-( | 08:06 |
| chriadam | and might be indicative that secrets api is broken in some sense | 08:06 |
| dcaliste | I mean, here, pluginName must be single, since we're signing the mail once with a given technic, while keyNames and collectionNames can be multiple, yes. | 08:07 |
| dcaliste | Well, I think that only PGP allows multi signers. I'm not sure S/MIME allows to do it. | 08:07 |
| chriadam | wait, are you saying "sign an email with multiple keys"? | 08:07 |
| chriadam | ah | 08:07 |
| dcaliste | Yes I do. | 08:07 |
| dcaliste | In Sailfish context, it's almost no use. But I don't want to restrict the backend to UI constrains. | 08:08 |
| chriadam | true | 08:08 |
| dcaliste | So the backend allows multi key signatures up to the setting (that can be changed by CLI). | 08:08 |
| dcaliste | Of course, UI will allow to set only one key… | 08:09 |
| chriadam | sure, that makes sense, I just hadn't considered that | 08:09 |
| chriadam | in this context. I know you had mentioned it before but that had slipped my mind | 08:09 |
| chriadam | so, yes, I guess there can only be one pluginName for this "default signing key(s)" case. | 08:10 |
| dcaliste | But I agree to use crypto/sign(bool), crypto/kyNames(as), crypto/coolectionNames(as) and crypto/pluginName(s). | 08:10 |
| dcaliste | Without misspell… | 08:10 |
| dcaliste | I will adjust QMF account setting API accordingly. | 08:11 |
| chriadam | sounds great, thanks | 08:12 |
| dcaliste | And to conclude this topic, then in the EmailComposer component, the setting are read and a checkbox is generated if crypto/keyNames and friends are defined and checked or not depending on crypto/sign boolean value. | 08:13 |
| dcaliste | So when the user is composing the email, there is nothing to change except if one wants to exceptionally sign the email or on the contrary not sign a specific one. | 08:13 |
| dcaliste | Then, crypto/keyNames and friends are passed to nemo-qml-plugin-email API when sendMessage() is called. | 08:14 |
| chriadam | sounds good. in the "exception" cases, the user just clicks the checkbox in the email composer (to either enable it if the default was disable but valid keys exist, or disable it if default was enable and valid keys exist), and then n-q-p-e does its thing based on the value of that checkbox (passed as a param I guess?) | 08:14 |
| dcaliste | And QMF through the plugin will eventually call the pinentry to ask for the passphrase to unlock the private keys. | 08:15 |
| chriadam | great | 08:15 |
| dcaliste | chriadam: yes about your rephrasing, that's it. | 08:15 |
| dcaliste | I've added properties to EmailMessage in nemo-qml-plugin-email. | 08:16 |
| chriadam | cool. I mean, sounds fine to me. maybe jpetrell or pvuorela will have some comments during review. I believe that jpetrell is testing it today/tomorrow. | 08:16 |
| dcaliste | Great. | 08:16 |
| chriadam | we still need to discuss internally more about dirmngr I gues | 08:16 |
| jpetrell | yeah compiling as we speak | 08:16 |
| dcaliste | jpetrell: good ! | 08:16 |
| dcaliste | Many packages are impacted which make the full thing not very easy to test and easily broken before proper tagging has been done. | 08:17 |
| dcaliste | chriadam: there is one bug that I cannot sort out myself, see https://bitbucket.org/jolla/ui-jolla-settings-accounts/pull-requests/29/wip-jolla-settings-accounts-add-crypto-key/diff | 08:18 |
| dcaliste | It's about setting an account of type string array from QML. I've got error doing it that I cannot understand. | 08:19 |
| dcaliste | It's all reported as comment in the mentionned PR. | 08:19 |
| dcaliste | Basically, this is failing : account.setConfigurationValue(_defaultServiceName, "crypto/ids", ["test"]) | 08:20 |
| chriadam | I remember you mentioning that case. I checked the code, and it has handling for QStringList and QVariantList (the latter it attempts to convert to QStringList) | 08:20 |
| chriadam | however clearly in your case it is detecting the type as uint32_t | 08:21 |
| chriadam | which is ... strange | 08:21 |
| chriadam | do you have access to sailfish-components-accounts? | 08:21 |
| dcaliste | If you cannot see obvious mistake from my side, and you don't have time, may I request access to the repo ? I can give a look myself like that. | 08:21 |
| dcaliste | Currently no. | 08:22 |
| chriadam | jpetrell: can dcaliste be given access to sailfish-components-accounts by any chance? | 08:22 |
| jpetrell | sure | 08:22 |
| dcaliste | Thanks, so I can debug it myself. | 08:22 |
| chriadam | dcaliste: be warned: dragons in there. I was pretty clueless about a&sso (and accounts domain in general) when I wrote those bindings. | 08:22 |
| dcaliste | No problem, will just add some printf here and there to understand why my type is thought as a uint32. | 08:23 |
| jpetrell | done | 08:24 |
| dcaliste | jpetrell, I see, thank you. | 08:24 |
| dcaliste | Will try the debug later today. | 08:24 |
| chriadam | dcaliste: good luck | 08:25 |
| dcaliste | Thank you chriadam for the discussion today about the implementation details. I appreciate. | 08:25 |
| chriadam | thank you as always for your time and effort | 08:25 |
| dcaliste | Maybe one last point about possible later migration. | 08:25 |
| chriadam | and willingness to jump into dangerous waters ;-) | 08:25 |
| chriadam | sure? | 08:25 |
| dcaliste | Currently crypto/pluginName contains "libgpgme.so" which is the QMF plugin name for PGP signature (I know name is not well chosen, since the other one is libsmime.so for GpgMe based S/MIME stuff)… | 08:27 |
| dcaliste | If at one moment we decide to ship a secret-based QMF plugin. How can we propagate the change to the user ? | 08:27 |
| dcaliste | I mean, it's a bit harsh to change his setting on SFOS update. | 08:28 |
| dcaliste | But it's borring to go to the setting page and ask him to redo the combo and choose the right plugin for his key. (and he may not care anyway). | 08:28 |
| chriadam | dcaliste: most likely we would migrate the setting automatically | 08:29 |
| chriadam | see the sailfish-accounts-tool in the sailfish-components-accounts repo | 08:29 |
| chriadam | we already migrate a bunch of settings automatically which changed in previous versions | 08:29 |
| dcaliste | Ok, I see, we migrate the values for a given key for each account I guess. So indeed setting "libgpgme.so" should not be a big ssue if we change name after release or ship another default plugin. | 08:30 |
| chriadam | I believe that would be fine | 08:31 |
| dcaliste | Because another solution would be to use some magic names like "default PGP plugin" which would convert automatically in QMF. | 08:31 |
| dcaliste | And allow to change the default by upgrading a package. | 08:32 |
| chriadam | perhaps. I have no strong feelings either way, except to say that we already do account setting migrations as a matter of course, so I don't see any reason why not to do that for this case | 08:32 |
| chriadam | but I agree that that may be suboptimal. e.g. a big reason why downgrades break things, is these single-direction migrations... | 08:33 |
| dcaliste | Ok, as long as it's a change in setting value, it's Jolla decision for the OS and it's fine with me. So I don't see any blocker for using crypto/pluginName(string) and let this field be whatever. I was a bit concern about future evolution but it's fine now. | 08:34 |
| chriadam | well, let's go with this for now and maybe discuss it going forward - definitely I'm always more ears about how to make upgrades+downgrades smoother / less maintenance effort / etc | 08:37 |
| chriadam | and your thoughts on that matter would of course be appreciated. I do see the benefit in allowing QMF to treat the value as a parameter which it can then translate into a "real" plugin name, but there are tradeoffs etc | 08:38 |
| chriadam | anyway I guess that discussion shouldn't block this effort for now at all :-) | 08:38 |
| dcaliste | chriadam: ok. I'll update PR with new setting names in the coming days, and try to debug the string array issue later today. | 08:38 |
| chriadam | great. thanks very much | 08:39 |
| chriadam | hopefully Joona has some concrete feedback on the PRs also | 08:39 |
| dcaliste | jpetrell: regarding your mention of calligra update in the last community meeting, I've gave a look at it. | 08:39 |
| dcaliste | I'm currently trying to compile latest 3.1.0 version in SDK. | 08:40 |
| dcaliste | I would prefer to separate kf5 stuff from calligra tree (currently, required kf5 packages have been added into calligra tree). | 08:40 |
| dcaliste | I've seen that rainemak has already included in mer some kf5 packages like extra-cmake-modules and karchive. | 08:41 |
| chriadam | I would greatly prefer if we could avoid any kf5 dependency also honesetly | 08:41 |
| dcaliste | I'm doing the same in https://git.merproject.org/dcaliste, see new kf5 packages. | 08:42 |
| dcaliste | chriadam: yes, but calligra is like qmf, not based on upstream and a diverged git repo. | 08:42 |
| dcaliste | It's complicated to upgrade with latest upstream. | 08:42 |
| dcaliste | I'm trying to use pristine upstream with some patches in build system to cut out as many kf5 dependencies as possible. | 08:43 |
| dcaliste | It is adding a lot of small packages into Mer which is cumbersome, I agree, bt at the same time these packages are maintained by someone else (KDE team). | 08:43 |
| chriadam | (my personal opinion would be: if those are necessary, we should bundle them into the calligra/sailfish-docs application package, rather than making them a system library / dependency) | 08:47 |
| chriadam | but I'm no expert | 08:47 |
| chriadam | my mantra is: reduce external dependencies, reduce system platform surface | 08:47 |
| chriadam | but of course there are very good reasons to ignore my mantra on occasion ;-) | 08:48 |
| chriadam | jpetrell may be eating lunch at the moment, not sure | 08:48 |
| jpetrell | I am here | 08:49 |
| chriadam | I stand corrected :-D | 08:49 |
| dcaliste | chriadam: I see your point. Do you think, doing something like that would be a merged position: | 08:49 |
| dcaliste | calligra/upstream (git submodule) | 08:49 |
| dcaliste | calligra/ki18n (git submodule) | 08:50 |
| dcaliste | calligra/kcodecs (git submodule) | 08:50 |
| dcaliste | calligra/… (all required kf5 git submodule) | 08:50 |
| dcaliste | calligra/rpm/patches | 08:50 |
| dcaliste | and the spec builds all kf5 modules before going into upstream and build the final library ? | 08:51 |
| dcaliste | Like that we are still based on upstream and upgrading is a matter of git pull and maintain patches. | 08:51 |
| chriadam | i.e. making a monolithic repository out of a bunch of dependencies + calligra? yes, to me that makes sense. but that's just an off-the-cuff personal opinion | 08:51 |
| dcaliste | Yes, but the monolithic repo should be based on git submodule to follow upstream, and not a copy like it is now. | 08:52 |
| chriadam | although I personally don't like rpm/patches, and prefer using git to store our delta to upstream, in each submodule, personally | 08:52 |
| chriadam | yes, definitely git submodule makes sense | 08:52 |
| dcaliste | Because with the current situation, it's a mess to follow upstream IMHO because there is no common ancestors. | 08:53 |
| r0kk3rz | ideally there is no patches | 08:53 |
| dcaliste | jpetrell (and lbt ^), what's your opinion on the shape of the calligra repo ? | 08:54 |
| lbt | mmm | 08:54 |
| jpetrell | I am no calligra expert. as such alligra upgrade would be awesome | 08:54 |
| dcaliste | r0kk3rz, yes I agree, but currently the calligra build system requires too many things while wanting to just create some parts. | 08:55 |
| lbt | there seems to be a huge backlog ... | 08:55 |
| dcaliste | For instance, it requires KAuth (priviledge escalation) to build word part (document rendering). | 08:55 |
| lbt | one thing I see relates to a number of repos... | 08:56 |
| lbt | we recently gained the ability to create depth in the git repo hierarchy eg: https://git.merproject.org/mirror/SWI-Prolog | 08:56 |
| dcaliste | lbt: in short should we import into Mer many kf5 packages and make them system packages, or should one put them into the calligra repo via git submodules. | 08:56 |
| lbt | I doubt there's a simplistic answer | 08:57 |
| pvuorela | likely case by case. | 08:57 |
| dcaliste | r0kk3rz, I would be happy though to submit build system modifications upstream. I've asked for a KDE account. I'm waiting for validation on their side. | 08:57 |
| dcaliste | pvuorela and lbt, you can see in https://git.merproject.org/dcaliste the various kstuff packages I'm adding. Still some are missing for calligra build. | 08:58 |
| lbt | OK - just reading more backlog | 09:00 |
| dcaliste | lbt chriadam pvuorela and jpetrell so my proposition is to continue adding and packaging kstuff in https://git.merproject.org/dcaliste up to the moment latest calligra can build with minimal patches to its build system. Then we can discuss which kpackage is worth having as a system library and which one can be packaged inside calligra repo. | 09:01 |
| chriadam | to me that sounds like a very sensible suggestion | 09:02 |
| pvuorela | dcaliste: sounds good to me. generally i think we should just have system packages for system library dependencies. nothing else might not use now, but can enable easier packaging later. | 09:02 |
| jpetrell | yeah sounds good | 09:02 |
| lbt | so essentially we're not making git/rpm packages for dependencies | 09:02 |
| lbt | calligra will run a big build whenever any of the git packages change and all compiles will happen in a single OBS job which is stiched together into a single(ish) rpm ? | 09:03 |
| chriadam | doesn't have to be a single rpm | 09:03 |
| lbt | (ish) | 09:04 |
| lbt | :) | 09:04 |
| lbt | ok - single spec file | 09:04 |
| lbt | ish | 09:04 |
| lbt | :) | 09:04 |
| chriadam | yes | 09:04 |
| lbt | I think that sounds clean | 09:04 |
| lbt | I would very strongly encourage the prolog-like mirror system | 09:05 |
| dcaliste | Ok, so step one: | 09:05 |
| lbt | so I see a master git repo which has no upstream source but many upstream submodules? | 09:05 |
| lbt | ie our packaging git repo | 09:05 |
| lbt | is that right? | 09:06 |
| pvuorela | dcaliste: and for calligra, it's diverged a lot because our fork was some sort of prototyping for qt5 port. might be easiest just sort of ditching our current version and packaging upstream. | 09:06 |
| chriadam | lbt: I believe so. we may have some UI components or some such in the "main" repo also, but not 100% sure on that. e.g. for embedding document views into email app etc | 09:06 |
| dcaliste | pvuorela: yes that's my understanding and what I'm doing in fact! | 09:07 |
| pvuorela | dcaliste: good :) | 09:07 |
| lbt | chriadam: agree - kinda talking guiding principles - until they break or hit the real world | 09:07 |
| dcaliste | - step one, create packages for every kf5 dependency in dcaliste for on going work (it avoid long rebuild of everything at each spec modification). | 09:07 |
| dcaliste | - step two ensure that upstream calligra is building (and potentially also working). | 09:07 |
| lbt | dcaliste: ok - step 1 is almost the opposite of what I thought | 09:07 |
| dcaliste | - step three move all kpackage denpendencies as git sub modules | 09:08 |
| lbt | maybe step X fixes that :) | 09:08 |
| lbt | haha | 09:08 |
| dcaliste | Well thinking about it, I can start at step three indeed ;) | 09:09 |
| dcaliste | No need to work on the spec file first. | 09:09 |
| dcaliste | Can do old cmake && make by hand first. | 09:09 |
| dcaliste | So let's change into: | 09:09 |
| lbt | and do you see the master git repo as basically pure packaging ? | 09:09 |
| dcaliste | - step one, move all my little kstuff into git submodule of the main calligra repo. | 09:10 |
| dcaliste | lbt: yes. | 09:10 |
| lbt | chriadam: I see no problem pulling any given dependency out of calligra and into a standalone package and introducing a BRequire - yes? | 09:11 |
| pvuorela | the kstuff does have potential to be used with other projects so i'm not sure i'd like to see it all in submodules. | 09:11 |
| dcaliste | - step two, make calligra a submodule and make it build based on previously compiled little kstuff. | 09:11 |
| dcaliste | - step three: move out little kstuff that can be usefull for someone else. | 09:11 |
| chriadam | lbt: I don't like increasing / proliferating packages which then easily become dependencies for yet other packages which may get added, personally. | 09:11 |
| lbt | pvuorela: see what I just said to chriadam | 09:12 |
| lbt | chriadam: see what pvuorela just said | 09:12 |
| chriadam | pvuorela's reasoning is the very reason why I _don't_ want it packaged separately, honestly ;-) | 09:12 |
| lbt | so I think both points are valid | 09:12 |
| dcaliste | Ah, let say we have two options: ;) | 09:12 |
| lbt | and what if we have another KDE app ported? | 09:13 |
| pvuorela | chriadam: how come? | 09:13 |
| dcaliste | - option one: package all kstuff as submodule of calligra and decide after which ones are usefull outside. | 09:13 |
| r0kk3rz | kstuff is like tribbles, before you know it you're up to your eyeballs in them | 09:13 |
| lbt | dcaliste: +1 that's what chriadam would like too | 09:13 |
| dcaliste | - option two: package everything as independent packages in git.merproject.org/dcaliste and decide after what should be useless and packages inside calligra. | 09:14 |
| * lbt ponders what chriadam said earlier | 09:14 | |
| lbt | dcaliste: there's no reason we cannot package everything using the calligra spec | 09:15 |
| chriadam | pvuorela: very briefly, my reasoning is: we should LIMIT our "platform surface" (i.e. the packages which we provide in our platform, and can be depended on) as much as possible. this ensures that we can minimise the maintenance effort, security attack surface, etc. we should try (as best as possible) to have one (and only one) way to do any given thing, and ensure it works properly/securely/performantly. then, if some | 09:15 |
| chriadam | application needs some dependency, they can bundle it (e.g. flatpak style) if necessary. | 09:15 |
| chriadam | as I mentioned, my mantra is: reduce external dependencies, and reduce platform surface. | 09:15 |
| lbt | we may be lazy and have libcalligradeps.rpm but we may also package the deps properly at some point | 09:15 |
| *** birdzhang_ is now known as birdzhang | 09:15 | |
| chriadam | but as I mentioned: maybe my mantra is wrong in some cases and should be ignored ;-) | 09:16 |
| lbt | chriadam: I concurr - but we don't have ~flatpak yet | 09:16 |
| dcaliste | lbt: I agree. It's a decision of Mer people what they want exposed and what not. I can do what ever you prefer. Just need someone to take the decision ;) | 09:16 |
| chriadam | lbt: but every step we take in the opposite direction makes it harder ot reach that goal | 09:16 |
| chriadam | see my arguments about the access control service etc also ;-) | 09:16 |
| r0kk3rz | tbh it would be nice to have a few more mer-* buckets than just mer-core for this reason | 09:16 |
| pvuorela | chriadam: then again some of that kstuff can take away maintenance burden from ourselves. | 09:17 |
| lbt | chriadam: I'm not averse to having calligra be an experiment with all the kde inside /usr/lib/calligra/lib/libk??.so | 09:17 |
| pvuorela | and of course there are different levels of kstuff. tier 1 should depend on qt only and thus better than the ones with more complex dependencies. | 09:17 |
| lbt | is that a step in the right direction? | 09:17 |
| chriadam | lbt: I personally think that's a step in the right direction | 09:18 |
| lbt | chriadam: I do see some conflict in your statement... "we should try (as best as possible) to have one (and only one) way to do any given thing" | 09:19 |
| lbt | vs "if some application needs some dependency, they can bundle it (e.g. flatpak style) if necessary" | 09:19 |
| lbt | so which is it? :D | 09:19 |
| dcaliste | pvuorela: From my point of view, kstuff are maintain by KDE team anyway, it's just packaging for us, which is almost zero effort (I think you share the same pov). But allowing them to be installed in /usr/lib makes the full system have a bigger size in term of potential bug, attack… | 09:19 |
| lbt | for eg kconfig? | 09:19 |
| chriadam | by "we" I mean Sailfish OS "the platform" | 09:19 |
| chriadam | so Sailfish OS the platform doesn't need to include all that jazz. then, some application which gets installed optionally into Sailfish OS (like Calligra) has some external dependencies, which it should bundle and install with itself. | 09:20 |
| lbt | chriadam: and when "we" have multiple kde apps? | 09:20 |
| lbt | (You know I'm not really arguing) | 09:20 |
| chriadam | again, flatpak runtimes would help with this case | 09:20 |
| chriadam | but in general I would say: too bad | 09:20 |
| lbt | so kde apps are 2nd class? | 09:21 |
| chriadam | constantly increasing our platform is a bad solution IMO | 09:21 |
| pvuorela | chriadam: not sure about that one. calligra in this case is a lib, not an app. | 09:21 |
| lbt | chriadam: why? look at Debian! What could possibly go wrong? | 09:21 |
| lbt | :D | 09:21 |
| chriadam | hehe | 09:21 |
| chriadam | pvuorela: I agree that it becomes tricky when something wishes to "extend the platform" in some way (e.g. provide some view which can be integrated into the rest of the system somehow, e.g. document views in jolla-email app or similar). | 09:22 |
| dcaliste | Do you agree all on having all kstuff in calligra first as submodules and then decide package per package if it's worth to package them separately (because we may use another KDE app, or like karchive we want to use it for Sailfish own stuff) ? | 09:22 |
| lbt | dcaliste: if you could keep in mind installing the dependencies inside a calligra tree (build-time configurable) that would be cool | 09:23 |
| chriadam | dcaliste: I think that's a fine suggestion, yes. we can decide the packaging concretely later | 09:23 |
| chriadam | pvuorela: but even then I'm not sure. those dependencies can be bundled and loaded as required, without requiring expanding the platform surface, IMO | 09:23 |
| lbt | dcaliste: even if we want them for other apps the calligra spec can build an rpm that other apps can depend on | 09:23 |
| chriadam | I have to head home, it's getting late. thanks for the discussion and your hard work, dcaliste :-) | 09:29 |
| dcaliste | chriadam, sure. See you later. | 09:29 |
| dcaliste | lbt: ok, so I'm going to change what I've done in g.m.o/dcaliste to include all kstuff as submodule of a new calligra repo. And install them inside the calligra tree. | 09:31 |
| dcaliste | Then, when done and calligra compiles I'll ping again and we can discuss what can be moved as standalone package. | 09:31 |
| lbt | dcaliste: may I check your terminology | 09:38 |
| dcaliste | lbt: sure, what do you mean? | 09:39 |
| lbt | so you'll make all the kstuff, including the main calligra git src repo, submodules of a mer-owned git packaging/build repo | 09:39 |
| dcaliste | lbt: yes. | 09:40 |
| dcaliste | And the install dir of the kstuff will be /usr/lib/calligra, not /usr/lib. | 09:40 |
| lbt | cool - and then you'll install them to /usr/lib/$SOMETHING which could be null and they'll be 'system' installed or it could be "calligra" and they'll be in the calligra tree/namespace | 09:41 |
| dcaliste | lbt: hopefully yes. I don't know exactly how to do this in a spec file (no problem to do it by hand), but I'll find ;) | 09:41 |
| lbt | the spec file can produce multiple rpms - eg a set per git submodule (lib, -dev etc) or you may be lazy to start and just bundle it into a big calligra rpm in the spec file | 09:42 |
| dcaliste | The problem I see is not rpm creation. Is that the built kstuff should be visible from calligra build tree while they are not yet installed. | 09:43 |
| dcaliste | I'm doing this at work all the time for physics related computational codes but with autotools. | 09:43 |
| dcaliste | I need to see how to achieve this with cmake. | 09:43 |
| lbt | so it's playing with ... yeah | 09:44 |
| lbt | cmake | 09:44 |
| lbt | w00t is around from time to time too - iirc he knew this stuff | 09:44 |
| dcaliste | Thanks, I will try and come back to him if I'm stuck at one moment. | 09:45 |
| lbt | sounds like a good plan - thanks! | 09:45 |
| pvuorela | though if there are problems, i'd most rather just have a newer calligra :) | 09:46 |
| dcaliste | It's an interesting challenge ;) Will see. | 09:46 |
| lbt | it should be do-able | 09:47 |
| dcaliste | pvuorela? I'm packaging latest (well almost latest, let say latest stable). | 09:47 |
| lbt | doing personal/devel builds without a make install in between is not unusual | 09:47 |
| lbt | also adding the BUILDROOT to the various LIB paths may just work | 09:48 |
| dcaliste | lbt: yes I've figured out that it's not what it has been designed to work with. But in Autotools, playing with env variables or --with-package=$strangeInstallDir usually solves the issue (depends on how detection macros are written though). | 09:49 |
| dcaliste | lbt: by the way, are you mirroring git://anongit.kde.org already ? It seems that karchive in mer is still using the upstream git repo. | 09:53 |
| lbt | I think we should create a kde section in the mirrors | 09:54 |
| dcaliste | Ok, as you prefer. When ready, I'll update the submodule paths. | 09:55 |
| kimmoli | does it work with Sailfish? http://hettarer.biz/ | 14:27 |
| xenu | it's a scam | 14:32 |
| kimmoli | no shit sherlock | 14:32 |
| *** mikkoh_ is now known as mikkoh | 14:33 | |
| *** phlixi is now known as phlixi_ | 16:48 | |
| Mister_Magister | hmm im using silica slider as proggressbar to my video and the problem is i want it to: follow video playing proggress and seek when i change value | 19:21 |
| Mister_Magister | the problem is that i can set slider to follow video but if i add onValueChanged to seek it will seek every time video plays | 19:22 |
| Mister_Magister | any idea? | 19:22 |
| elros | ther is down property which you can use | 19:25 |
| kimmoli | did that somewhere, but dont remember how and where.. | 19:25 |
| mal | Mister_Magister: https://github.com/joonne/harbour-nayttamo/blob/master/qml/pages/PlayerPage.qml#L130 | 19:29 |
| Mister_Magister | elros: mal: thanks! | 19:32 |
| Mister_Magister | how can i use acceptDestinationProperties to set variable in destination page? | 21:04 |
| *** feodoran is now known as Guest99931 | 23:11 | |
| *** feodoran_ is now known as feodoran | 23:11 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!