Tuesday, 2018-08-14

*** frinring_ is now known as frinring01:01
rydarekimmoli: you have a oneplus x right?  have you had any issues with inaccurate battery percentages?01:26
rydareI'm seeing a post form 2016-03-20, about battery reading 100% for a day.  I think that's what i'm experiencing01:34
rydareit went down to 99%01:39
rydareso maybe it is working?01:39
rydarehad the same issue the other day, was at 100 until it suddenly went to 49%01:40
kimmolirydare: yes, that bug is there04:23
kimmolii thgouht i fixed it, but not completely. the kernel bms tries to smooth that value, and the logic is kinda complicated04:25
kimmoliso it gets stuck in 99/100% or just at 100%.04:25
kimmoliplug in charger for few secs, and it should normalize slowly.04:25
dcalisteHello chriadam, jpetrell, sorry to be that late today.07:26
chriadamdcaliste: hi, no problem07:29
dcalisteI 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
dcalisteok, it's about the email composition.07:32
dcalistePGP (or S/MIME) are attached to an email. It's not a technical constrain, it's just metadata.07:32
dcalisteSo, in the composer, the UI should propose the user to sign the outgoing mail with the key associated to the email address.07:33
dcalisteOne 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
dcalisteIMHO it's a bit too much for most of the time, since there may be no PGP key associated to this address.07:34
dcalisteThe 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
chriadamWe could instantiate a SecretManager (singleton or otherwise) in the email application always, and then only perform the request when needed07:36
dcalisteIn 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
dcalisteThe Composer is a component that is not always used in the context of the email application, I think.07:37
chriadamI mean, using an account setting makes sense also07: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
dcalisteI'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
dcalisteThe same key can be used for several email address.07:39
dcaliste(for PGP).07:39
dcalisteThere can be several email addresses attached to a single key.07:39
dcalisteBut normally, you should have only one key for a given email address.07:40
dcalisteBut technically, it's not a constrain…07:40
chriadamwhen 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
dcalisteI've decided that they are the same.07:41
dcalisteI'm using the PGP fingerprint as the key identifier name in Secret.07:42
dcalisteThis is also a debatable choice ;)07:42
chriadamwell I more meant: does it include plugin+collectionName info07:43
dcalisteNo. identifier.name() == fingerprint, identifier.collectionName() == user ID (allowing multi key for a given user), and identifier.storagePlugin() == PGP or S/MIME.07:45
dcalisteBy the way, the setting crypto/type contains the storagePlugin name.07:45
dcalisteThis will allow to be able to use several concurrent plugin for the same task if one wants to.07:46
chriadamah, 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
dcalisteFor 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
dcalisteWell, currently the composer is not using Secret at all.07:47
chriadamwhat does the signing?  just qmf?07:47
dcalisteIt is using the nemo-qml-plugin-email API.07:47
dcalisteWhich in turn is using a plugin in QMF.07:48
dcalisteWhich appears to be using gpgme directly. For the moment.07:48
dcalisteBut 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
chriadamright, I see07:50
chriadamthat's fine07:50
chriadamin the future, we can change qmf (or whatever) to call sailfish-secrets instead of gpgme when performing the signing07:51
pvuorelabtw, somewhat related, i'm now rebasing qmf against qt master. finally.07:51
chriadammy main concern with that is: eventually, that component will need "enough information" to appropriately construct a key identifier07: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
dcalistepvuorela : amazing. I've looked into both history and it's a total mess, not same ancestor, mixed commits…07:52
dcalistechriadam: you're concerns are right.07:52
pvuoreladcaliste: yep, hasn't been exactly pleasant, but i have now something, haven't yet compiled it though :)07:53
dcalisteI've not think in advance enough and didn't anticipate the collectionName issue when switching to secret API.07:53
dcalistepvuorela, congratulation I didn't dare to start it !07:54
pvuoreladcaliste: 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
dcalistepvuorela, 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
dcalisteShould 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
dcalistechriadam, 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
dcalisteIt's less nice in the UI when listing the keys though…07:57
pvuoreladcaliste: 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
dcalistepvuorela, ok I'll rebase my various commits in mer into upstream and submit PR there. Will do within three weeks I think.07:58
pvuoreladcaliste: thanks!08:00
dcalistechriadam, 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
dcalisteThis combo has always a "no sign please" entry in addition.08:01
chriadamso the user selects the "main" key they wish to use to sign emails with, at account creation time (or, account modify time..)08:02
dcalisteCurrently, 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
chriadamI 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
dcalisteWell, for each account they can select the kay they would like to use to sign by default.08:04
dcalisteOk, I can symmetrise the naming conventions.08:05
dcalisteBut I'm a bit concened by the fact that PGP is not exactly 1:1 with secret.08:05
chriadamit is problematic :-(08:06
chriadamand might be indicative that secrets api is broken in some sense08:06
dcalisteI 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
dcalisteWell, I think that only PGP allows multi signers. I'm not sure S/MIME allows to do it.08:07
chriadamwait, are you saying "sign an email with multiple keys"?08:07
dcalisteYes I do.08:07
dcalisteIn Sailfish context, it's almost no use. But I don't want to restrict the backend to UI constrains.08:08
dcalisteSo the backend allows multi key signatures up to the setting (that can be changed by CLI).08:08
dcalisteOf course, UI will allow to set only one key…08:09
chriadamsure, that makes sense, I just hadn't considered that08:09
chriadamin this context.  I know you had mentioned it before but that had slipped my mind08:09
chriadamso, yes, I guess there can only be one pluginName for this "default signing key(s)" case.08:10
dcalisteBut I agree to use crypto/sign(bool), crypto/kyNames(as), crypto/coolectionNames(as) and crypto/pluginName(s).08:10
dcalisteWithout misspell…08:10
dcalisteI will adjust QMF account setting API accordingly.08:11
chriadamsounds great, thanks08:12
dcalisteAnd 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
dcalisteSo 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
dcalisteThen, crypto/keyNames and friends are passed to nemo-qml-plugin-email API when sendMessage() is called.08:14
chriadamsounds 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
dcalisteAnd QMF through the plugin will eventually call the pinentry to ask for the passphrase to unlock the private keys.08:15
dcalistechriadam: yes about your rephrasing, that's it.08:15
dcalisteI've added properties to EmailMessage in nemo-qml-plugin-email.08:16
chriadamcool.  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
chriadamwe still need to discuss internally more about dirmngr I gues08:16
jpetrellyeah compiling as we speak08:16
dcalistejpetrell: good !08:16
dcalisteMany packages are impacted which make the full thing not very easy to test and easily broken before proper tagging has been done.08:17
dcalistechriadam: 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/diff08:18
dcalisteIt's about setting an account of type string array from QML. I've got error doing it that I cannot understand.08:19
dcalisteIt's all reported as comment in the mentionned PR.08:19
dcalisteBasically, this is failing : account.setConfigurationValue(_defaultServiceName, "crypto/ids", ["test"])08:20
chriadamI 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
chriadamhowever clearly in your case it is detecting the type as uint32_t08:21
chriadamwhich is ... strange08:21
chriadamdo you have access to sailfish-components-accounts?08:21
dcalisteIf 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
dcalisteCurrently no.08:22
chriadamjpetrell: can dcaliste be given access to sailfish-components-accounts by any chance?08:22
dcalisteThanks, so I can debug it myself.08:22
chriadamdcaliste: be warned: dragons in there. I was pretty clueless about a&sso (and accounts domain in general) when I wrote those bindings.08:22
dcalisteNo problem, will just add some printf here and there to understand why my type is thought as a uint32.08:23
dcalistejpetrell, I see, thank you.08:24
dcalisteWill try the debug later today.08:24
chriadamdcaliste: good luck08:25
dcalisteThank you chriadam for the discussion today about the implementation details. I appreciate.08:25
chriadamthank you as always for your time and effort08:25
dcalisteMaybe one last point about possible later migration.08:25
chriadamand willingness to jump into dangerous waters ;-)08:25
dcalisteCurrently 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
dcalisteIf at one moment we decide to ship a secret-based QMF plugin. How can we propagate the change to the user ?08:27
dcalisteI mean, it's a bit harsh to change his setting on SFOS update.08:28
dcalisteBut 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
chriadamdcaliste: most likely we would migrate the setting automatically08:29
chriadamsee the sailfish-accounts-tool in the sailfish-components-accounts repo08:29
chriadamwe already migrate a bunch of settings automatically which changed in previous versions08:29
dcalisteOk, 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
chriadamI believe that would be fine08:31
dcalisteBecause another solution would be to use some magic names like "default PGP plugin" which would convert automatically in QMF.08:31
dcalisteAnd allow to change the default by upgrading a package.08:32
chriadamperhaps.  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 case08:32
chriadambut I agree that that may be suboptimal.  e.g. a big reason why downgrades break things, is these single-direction migrations...08:33
dcalisteOk, 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
chriadamwell, 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 / etc08:37
chriadamand 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 etc08:38
chriadamanyway I guess that discussion shouldn't block this effort for now at all :-)08:38
dcalistechriadam: 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
chriadamgreat.  thanks very much08:39
chriadamhopefully Joona has some concrete feedback on the PRs also08:39
dcalistejpetrell: regarding your mention of calligra update in the last community meeting, I've gave a look at it.08:39
dcalisteI'm currently trying to compile latest 3.1.0 version in SDK.08:40
dcalisteI would prefer to separate kf5 stuff from calligra tree (currently, required kf5 packages have been added into calligra tree).08:40
dcalisteI've seen that rainemak has already included in mer some kf5 packages like extra-cmake-modules and karchive.08:41
chriadamI would greatly prefer if we could avoid any kf5 dependency also honesetly08:41
dcalisteI'm doing the same in https://git.merproject.org/dcaliste, see new kf5 packages.08:42
dcalistechriadam: yes, but calligra is like qmf, not based on upstream and a diverged git repo.08:42
dcalisteIt's complicated to upgrade with latest upstream.08:42
dcalisteI'm trying to use pristine upstream with some patches in build system to cut out as many kf5 dependencies as possible.08:43
dcalisteIt 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
chriadambut I'm no expert08:47
chriadammy mantra is: reduce external dependencies, reduce system platform surface08:47
chriadambut of course there are very good reasons to ignore my mantra on occasion ;-)08:48
chriadamjpetrell may be eating lunch at the moment, not sure08:48
jpetrellI am here08:49
chriadamI stand corrected :-D08:49
dcalistechriadam: I see your point. Do you think, doing something like that would be a merged position:08:49
dcalistecalligra/upstream (git submodule)08:49
dcalistecalligra/ki18n (git submodule)08:50
dcalistecalligra/kcodecs (git submodule)08:50
dcalistecalligra/… (all required kf5 git submodule)08:50
dcalisteand the spec builds all kf5 modules before going into upstream and build the final library ?08:51
dcalisteLike that we are still based on upstream and upgrading is a matter of git pull and maintain patches.08:51
chriadami.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 opinion08:51
dcalisteYes, but the monolithic repo should be based on git submodule to follow upstream, and not a copy like it is now.08:52
chriadamalthough I personally don't like rpm/patches, and prefer using git to store our delta to upstream, in each submodule, personally08:52
chriadamyes, definitely git submodule makes sense08:52
dcalisteBecause with the current situation, it's a mess to follow upstream IMHO because there is no common ancestors.08:53
r0kk3rzideally there is no patches08:53
dcalistejpetrell (and lbt ^), what's your opinion on the shape of the calligra repo ?08:54
jpetrellI am no calligra expert. as such alligra upgrade would be awesome08:54
dcalister0kk3rz, yes I agree, but currently the calligra build system requires too many things while wanting to just create some parts.08:55
lbtthere seems to be a huge backlog ...08:55
dcalisteFor instance, it requires KAuth (priviledge escalation) to build word part (document rendering).08:55
lbtone thing I see relates to a number of repos...08:56
lbtwe recently gained the ability to create depth in the git repo hierarchy eg: https://git.merproject.org/mirror/SWI-Prolog08:56
dcalistelbt: 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
lbtI doubt there's a simplistic answer08:57
pvuorelalikely case by case.08:57
dcalister0kk3rz, 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
dcalistepvuorela 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
lbtOK - just reading more backlog09:00
dcalistelbt 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
chriadamto me that sounds like a very sensible suggestion09:02
pvuoreladcaliste: 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
jpetrellyeah sounds good09:02
lbtso essentially we're not making git/rpm packages for dependencies09:02
lbtcalligra 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
chriadamdoesn't have to be a single rpm09:03
lbtok - single spec file09:04
lbtI think that sounds clean09:04
lbtI would very strongly encourage the prolog-like mirror system09:05
dcalisteOk, so step one:09:05
lbtso I see a master git repo which has no upstream source but many upstream submodules?09:05
lbtie our packaging git repo09:05
lbtis that right?09:06
pvuoreladcaliste: 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
chriadamlbt: 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 etc09:06
dcalistepvuorela: yes that's my understanding and what I'm doing in fact!09:07
pvuoreladcaliste: good :)09:07
lbtchriadam: agree - kinda talking guiding principles - until they break or hit the real world09: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
lbtdcaliste: ok - step 1 is almost the opposite of what I thought09:07
dcaliste- step three move all kpackage denpendencies as git sub modules09:08
lbtmaybe step X fixes that :)09:08
dcalisteWell thinking about it, I can start at step three indeed ;)09:09
dcalisteNo need to work on the spec file first.09:09
dcalisteCan do old cmake && make by hand first.09:09
dcalisteSo let's change into:09:09
lbtand 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
dcalistelbt: yes.09:10
lbtchriadam: I see no problem pulling any given dependency out of calligra and into a standalone package and introducing a BRequire - yes?09:11
pvuorelathe 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
chriadamlbt: I don't like increasing / proliferating packages which then easily become dependencies for yet other packages which may get added, personally.09:11
lbtpvuorela: see what I just said to chriadam09:12
lbtchriadam: see what pvuorela just said09:12
chriadampvuorela's reasoning is the very reason why I _don't_ want it packaged separately, honestly ;-)09:12
lbtso I think both points are valid09:12
dcalisteAh, let say we have two options: ;)09:12
lbtand what if we have another KDE app ported?09:13
pvuorelachriadam: how come?09:13
dcaliste- option one: package all kstuff as submodule of calligra and decide after which ones are usefull outside.09:13
r0kk3rzkstuff is like tribbles, before you know it you're up to your eyeballs in them09:13
lbtdcaliste: +1 that's what chriadam would like too09: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 earlier09:14
lbtdcaliste: there's no reason we cannot package everything using the calligra spec09:15
chriadampvuorela: 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 some09:15
chriadamapplication needs some dependency, they can bundle it (e.g. flatpak style) if necessary.09:15
chriadamas I mentioned, my mantra is: reduce external dependencies, and reduce platform surface.09:15
lbtwe may be lazy and have libcalligradeps.rpm but we may also package the deps properly at some point09:15
*** birdzhang_ is now known as birdzhang09:15
chriadambut as I mentioned: maybe my mantra is wrong in some cases and should be ignored ;-)09:16
lbtchriadam: I concurr - but we don't have ~flatpak yet09:16
dcalistelbt: 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
chriadamlbt: but every step we take in the opposite direction makes it harder ot reach that goal09:16
chriadamsee my arguments about the access control service etc also ;-)09:16
r0kk3rztbh it would be nice to have a few more mer-* buckets than just mer-core for this reason09:16
pvuorelachriadam: then again some of that kstuff can take away maintenance burden from ourselves.09:17
lbtchriadam: I'm not averse to having calligra be an experiment with all the kde inside /usr/lib/calligra/lib/libk??.so09:17
pvuorelaand 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
lbtis that a step in the right direction?09:17
chriadamlbt: I personally think that's a step in the right direction09:18
lbtchriadam: 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
lbtvs "if some application needs some dependency, they can bundle it (e.g. flatpak style) if necessary"09:19
lbtso which is it? :D09:19
dcalistepvuorela: 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
lbtfor eg kconfig?09:19
chriadamby "we" I mean Sailfish OS "the platform"09:19
chriadamso 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
lbtchriadam: and when "we" have multiple kde apps?09:20
lbt(You know I'm not really arguing)09:20
chriadamagain, flatpak runtimes would help with this case09:20
chriadambut in general I would say: too bad09:20
lbtso kde apps are 2nd class?09:21
chriadamconstantly increasing our platform is a bad solution IMO09:21
pvuorelachriadam: not sure about that one. calligra in this case is a lib, not an app.09:21
lbtchriadam: why? look at Debian! What could possibly go wrong?09:21
chriadampvuorela: 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
dcalisteDo 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
lbtdcaliste: if you could keep in mind installing the dependencies inside a calligra tree (build-time configurable) that would be cool09:23
chriadamdcaliste: I think that's a fine suggestion, yes.  we can decide the packaging concretely later09:23
chriadampvuorela: but even then I'm not sure.  those dependencies can be bundled and loaded as required, without requiring expanding the platform surface, IMO09:23
lbtdcaliste: even if we want them for other apps the calligra spec can build an rpm that other apps can depend on09:23
chriadamI have to head home, it's getting late.  thanks for the discussion and your hard work, dcaliste :-)09:29
dcalistechriadam, sure. See you later.09:29
dcalistelbt: 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
dcalisteThen, when done and calligra compiles I'll ping again and we can discuss what can be moved as standalone package.09:31
lbtdcaliste: may I check your terminology09:38
dcalistelbt: sure, what do you mean?09:39
lbtso you'll make all the kstuff, including the main calligra git src repo, submodules of a mer-owned git packaging/build repo09:39
dcalistelbt: yes.09:40
dcalisteAnd the install dir of the kstuff will be /usr/lib/calligra, not /usr/lib.09:40
lbtcool - 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/namespace09:41
dcalistelbt: 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
lbtthe 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 file09:42
dcalisteThe 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
dcalisteI'm doing this at work all the time for physics related computational codes but with autotools.09:43
dcalisteI need to see how to achieve this with cmake.09:43
lbtso it's playing with ... yeah09:44
lbtw00t is around from time to time too - iirc he knew this stuff09:44
dcalisteThanks, I will try and come back to him if I'm stuck at one moment.09:45
lbtsounds like a good plan - thanks!09:45
pvuorelathough if there are problems, i'd most rather just have a newer calligra :)09:46
dcalisteIt's an interesting challenge ;) Will see.09:46
lbtit should be do-able09:47
dcalistepvuorela? I'm packaging latest (well almost latest, let say latest stable).09:47
lbtdoing personal/devel builds without a make install in between is not unusual09:47
lbtalso adding the BUILDROOT to the various LIB paths may just work09:48
dcalistelbt: 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
dcalistelbt: 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
lbtI think we should create a kde section in the mirrors09:54
dcalisteOk, as you prefer. When ready, I'll update the submodule paths.09:55
kimmolidoes it work with Sailfish? http://hettarer.biz/14:27
xenuit's a scam14:32
kimmolino shit sherlock14:32
*** mikkoh_ is now known as mikkoh14:33
*** phlixi is now known as phlixi_16:48
Mister_Magisterhmm 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 value19:21
Mister_Magisterthe problem is that i can set slider to follow video but if i add onValueChanged to seek it will seek every time video plays19:22
Mister_Magisterany idea?19:22
elrosther is down property which you can use19:25
kimmolidid that somewhere, but dont remember how and where..19:25
malMister_Magister: https://github.com/joonne/harbour-nayttamo/blob/master/qml/pages/PlayerPage.qml#L13019:29
Mister_Magisterelros: mal: thanks!19:32
Mister_Magisterhow can i use acceptDestinationProperties to set variable in destination page?21:04
*** feodoran is now known as Guest9993123:11
*** feodoran_ is now known as feodoran23:11

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