| dcaliste | Good evening chriadam, sorry to be late today. | 08:13 |
|---|---|---|
| chriadam | hi dcaliste, no problem at all | 08:15 |
| chriadam | how has your week been? | 08:15 |
| dcaliste | It was great thank you. I hope the same applies to yours. | 08:15 |
| chriadam | nice one! my week was ok, thanks | 08:15 |
| chriadam | some bad news about gnutls: management decided that they don't want it packaged as part of sailfishos | 08:16 |
| chriadam | at least, that's my understanding | 08:16 |
| dcaliste | Yes, I've seen the message of ViGe. Too bad. But anyway, it's not strictly speaking mandatory for GnuPG. | 08:17 |
| chriadam | cool | 08:17 |
| chriadam | it's just key exchange, or? | 08:17 |
| dcaliste | It's to allow certificate download with TLS. | 08:17 |
| dcaliste | Let put it aside at the moment. Worst case, if it appears it's boring without, would be to implement the functionality as a patch replacing GnuTLS with OpenSSL. It's just for download after. I didn't look at it closely, but it should not be that complicated. | 08:19 |
| chriadam | great | 08:19 |
| dcaliste | s/after/after all/ | 08:19 |
| Renaud[m] | Sorry to hear that gnutls won't be updated but if you can find a way to use the one in chum if it has been installed, it is available there | 08:19 |
| chriadam | thanks Renaud[m] | 08:20 |
| dcaliste | Yes, thank you Renaud[m], the problem is that we need it at compile time for GnuPG to get the functionality. | 08:20 |
| dcaliste | Thus my question : are you at Jolla ok with an upgrade of GnuPG in your repositories ? | 08:20 |
| dcaliste | Legaly speaking it has been stuck for licensing reasons. But we can do like for bash, which, and some other CLI tools : have a gnupg-gpl package that is up-to-date and leave untouched the gnupg-legacy as it is now. | 08:22 |
| chriadam | dcaliste: I'm not sure. I think our customers are greatly (L)GPLv3 averse | 08:22 |
| ViGe | dcaliste: No, we are not ok with that. | 08:23 |
| dcaliste | That's why it's not installed by default. Like gnu-bash at the moment. | 08:23 |
| ViGe | I believe the "no" for upgrading GnuPG is even stronger than upgrading GnuTLS. | 08:23 |
| chriadam | I suspect that gnu-bash will likely be removed at some point, honestly.. | 08:24 |
| dcaliste | ViGe, even as a separate package ? | 08:24 |
| dcaliste | Too bad, I thought the gnu-* packaging route was the future as a solution to be able to ship up-to-date pieces of software for devices that have root access (thus that comply with GPLv3 clause of being able to recompile and replace). | 08:25 |
| chriadam | I had hoped so, also | 08:25 |
| chriadam | and, technically, it should be. I think the aversion comes from our customers. | 08:26 |
| chriadam | having anything which might accidentally become a dependency... they see it as a risk. | 08:26 |
| ViGe | Exactly. If there is even a remote possibility that the package might end up in a device, even by accident, it's a "no". | 08:28 |
| dcaliste | So back to the black board to find a solution… | 08:30 |
| chriadam | unfortunately, it seems so. | 08:30 |
| dcaliste | As I mentioned in the GnuTLS PR comment, having it on chum is not bad, but it means that there is almost no possibility of UI integration. | 08:30 |
| dcaliste | Having a package in Jolla repo, even separated like the email-crypto one for the email application, will depend on something on chum. | 08:31 |
| dcaliste | That's utterly fragile. | 08:31 |
| chriadam | indeed | 08:32 |
| dcaliste | And I can see, the next step : removal of UI packages relying on chum stack. | 08:32 |
| chriadam | yeah, I think that dependencies on chum is not really feasible, long term | 08:32 |
| dcaliste | Compiling the UI part on chum is not possible neither, at least for integration in official applications, since sources are closed. | 08:32 |
| chriadam | potentially the sharing integration might be one way to talk to and from such a package... if it could be generic enough, and if the chum package registers a specific handler etc. | 08:33 |
| dcaliste | Well, thinking about email signature (and encription), honnestly, having as a true plugin of the email application would mean a lot of code changes… | 08:34 |
| chriadam | yeah :-/ | 08:35 |
| dcaliste | Without speaking of security implication of letting such plugin be possible… | 08:35 |
| chriadam | from sailfish-secrets side, it's not so big a deal: can have a plugin which is always installed, but which marks itself as disabled if some other third-party executable binary doesn't exist | 08:38 |
| chriadam | and so it can perform IPC calls to that binary to do whatever it needs | 08:38 |
| chriadam | (and so long as that plugin doesn't list anything as a dependency, it just "fails to work" if the other package isn't installed, but doesn't fail to build or whatever) | 08:38 |
| chriadam | I guess we might need to add some API to the secrets plugin interface "ready/active" (but I think that probably already exists, or should, since we need to deal with e.g. usb sticks being removed from the device) | 08:39 |
| chriadam | but ... that limits operations to just what is supported from the secrets/crypto API, which might not cover everythign required for such a deep integration use-case. | 08:40 |
| dcaliste | Yeh, I need to see how to reorganise all of this on chum. On the secret API side, there's already everything required as far as I remember. | 08:40 |
| dcaliste | Basically, it requires that the QMF plugin is built on chum (which is tricky, because main QMF will come from Jolla repo), and the same for the secret plugin. | 08:41 |
| chriadam | right, I think I see.. | 08:42 |
| dcaliste | Then, everything should be transparent at the UI level. | 08:42 |
| dcaliste | But it complexify a bit the build chain and the spec writing. | 08:42 |
| dcaliste | Anyway, thank you for merging the socket naming issue in password manager. I'm sorry it was not in the original PR. Obviously I had it for testing on device but it somehow disappeared in the commit process (?). | 08:43 |
| chriadam | all good, I'm not sure what happened, I probably broke something somehow. I swear I tested that codepath before I merged the original but apparently not. | 08:44 |
| dcaliste | The same for me, I was even using it on device up to the upgrade yesterday ! Anyway, I guess it still has time to get into 4.4.0 before release. | 08:45 |
| chriadam | yep, it's already been accepted into 4.4.0 line | 08:46 |
| chriadam | thank you for following up - greatly appreciated! | 08:46 |
| dcaliste | No problem, that's normal. Speaking about testing crypto thingies, there is still jolla-email#525 to get it feature complete with previous version. | 08:47 |
| dcaliste | I tried to get what can reset the rootContext, but I didn't find anything. There is no signal on context invalidation in the API as far I can see. | 08:48 |
| dcaliste | And there is no way in the Qt API neither to "reset" the rootContext. | 08:48 |
| chriadam | did you get a chance to see if the EmailService one was also causing problems? | 08:49 |
| chriadam | or if it was only the "emailAppCryptoEnabled" one which was problematic? | 08:50 |
| dcaliste | Indeed, the EmailService seems no affected : | 08:50 |
| chriadam | so strange | 08:50 |
| dcaliste | [D] onTriggered:73 - DeclarativeEmailService(0xb88a3000) true | 08:50 |
| dcaliste | [W] unknown:0 - Could not open "/usr/share/sailfish-browser/data/ua-update.json.in" | 08:50 |
| dcaliste | [D] onTriggered:73 - DeclarativeEmailService(0xb88a3000) true | 08:50 |
| dcaliste | [D] onTriggered:73 - DeclarativeEmailService(0xb88a3000) true | 08:50 |
| dcaliste | [D] onTriggered:73 - DeclarativeEmailService(0xb88a3000) false | 08:50 |
| dcaliste | Its a 100ms timer printing the EmailService and the "emailAppCryptoEnabled" values. | 08:50 |
| dcaliste | My guess here is that the EmailService is a QObject while the other property is a simple bool. | 08:51 |
| dcaliste | So whatever happened to the root context seems to preserve pointers on QObjects. | 08:51 |
| chriadam | ah... | 08:52 |
| chriadam | huh | 08:52 |
| chriadam | that suggests a solution... | 08:52 |
| dcaliste | But it's highly speculative speach here. I think I looking at it from the wrong angle, but I've no idea how to understand it right. | 08:52 |
| chriadam | a bit ugly, but ... the value could be a `new QObject(engine)` if true, or `nullptr' if false... | 08:53 |
| chriadam | if that one still doesn't resolve it, then we know that it's not specifically to do with the context, but must be being manually set by something, I guess | 08:53 |
| dcaliste | Yes, I can easily try this. | 08:53 |
| chriadam | thanks. I've poked Pekka on that review also | 08:54 |
| dcaliste | I was ready to bet that it's a manual reset of the specific property, but grepping for it only returns this : | 08:54 |
| dcaliste | ./src/email.cpp: view->rootContext()->setContextProperty("emailAppCryptoEnabled", | 08:55 |
| dcaliste | Fichier binaire ./src/email.o correspondant | 08:55 |
| dcaliste | ./email.qml: _hasCryptoSupport = emailAppCryptoEnabled | 08:55 |
| dcaliste | So except if the main() is executed twice, there is no possibility to get this line executed again after the first time. | 08:55 |
| dcaliste | As far as I remember abou my initial testing I added some debug lines around there and they were only printed once. | 08:56 |
| chriadam | that note about "main" is interesting, actually... | 08:56 |
| chriadam | there might be some invoker things involved, we do build with -fPIE and probably run the entrypoint manually within the boosted process.. | 08:57 |
| chriadam | I wonder if there's a bug in that code, perhaps? in mapplauncherd or whatever... | 08:57 |
| chriadam | dcaliste: unfortunately I have a meeting I have to run to now - thank you for your time and effort as always. Please poke me on any PRs which might have slipped my notice (I've been mostly busy on another customer project this last week, and haven't had much time for other things) | 08:58 |
| chriadam | I hope that you have a great week! | 08:58 |
| dcaliste | Yes, that was my thinking also, but if debug lines of main are printed only once, then the main() is only executed once. And the fact that the memory address for the EmailService object is the same points me to a single execution. | 08:58 |
| chriadam | yes, that's true | 08:58 |
| chriadam | so, bug in QML is most likely. | 08:59 |
| chriadam | I mean, in the engine | 08:59 |
| dcaliste | You can have a look to https://github.com/sailfishos/nemo-qml-plugin-calendar/pull/13 when you have the time to. | 08:59 |
| chriadam | thanks, will do | 08:59 |
| dcaliste | Thanks, have a nice week (and a good meeting). | 09:00 |
| dcaliste | Ah, I forgot, I'll be unavailable next Tuesday. | 09:00 |
| chriadam | in that case, have a great two weeks ;-) | 09:00 |
| dcaliste | I've an electrical security training. | 09:00 |
| chriadam | hopefully it goes well ;-) I have to run - good night :-) | 09:01 |
| dcaliste | Bye, thanks. | 09:01 |
| Ingvix | waydroid users around? I was just wondering how does it currently compares to aliendalvik, not having tried it myself | 09:30 |
| Renaud[m] | piggz or rinigus could you activate compilation for 4.3 on gnutls package on chum, please? | 09:58 |
| rinigus | Renaud: sure. have you checked that it is not in conflict with 4.3 gnutls? | 10:00 |
| piggz | rinigus: lbt:looks like a DOD issue blocking | 10:00 |
| piggz | atleast the i486 target | 10:00 |
| piggz | Ingvix: not as integrated, meets my minimal androd needs (whatsapp, work/friends) | 10:01 |
| lbt | hmmm | 10:01 |
| Renaud[m] | gnutls hasn't been updated in 4.3 (and will probably never: https://github.com/sailfishos/gnutls/pull/1#issuecomment-973795165 ) | 10:01 |
| lbt | :( | 10:02 |
| piggz | lbt: cheer up | 10:02 |
| Renaud[m] | by the way, what does DOD mean? | 10:02 |
| lbt | Download On Demand | 10:02 |
| Ingvix | piggz, what android version is it equivalent? Does apps see it as rooted or not? | 10:03 |
| lbt | when it builds it needs dependencies... ie -devel rpms | 10:03 |
| piggz | Ingvix: 10, and i dont know | 10:03 |
| Ingvix | alright | 10:04 |
| Renaud[m] | and when it is blocking, does it mean the dependency is not found? | 10:04 |
| Ingvix | and I guess you wouldn't know if there are any other caveats in functionality outside the apps you use? | 10:04 |
| piggz | yeah, ive got whatsapp, twitter and the guardian, thats all! | 10:05 |
| lbt | no there's a stupid bug in the curl-like code which fails due to excess http redirects due to CDNs | 10:05 |
| rinigus | Renaud and piggz : in this light - should we just enable gnutls by default for all targets in chum? | 10:07 |
| Renaud[m] | I guess | 10:08 |
| lbt | is that a good idea? | 10:08 |
| lbt | it seems that it should be available but only used if there's really no alternative | 10:09 |
| Renaud[m] | it is packaged under another name, it won't conflict with the one in jolla repositories | 10:09 |
| lbt | (being honest I've not been paying enough attention - that's part of the problem, we're crazy busy at the minute) | 10:10 |
| rinigus | lbt: reference: https://build.sailfishos.org/package/view_file/sailfishos:chum/gnutls/_service:tar_git:gnutls.spec?expand=1 | 10:10 |
| rinigus | Renaud: I enabled it by default, let's see if we get problems with it later | 10:18 |
| rinigus | cc piggz and lbt ^ | 10:18 |
| Renaud[m] | great, thanks! | 10:18 |
| lbt | the blocking issue seems fixed... cc piggz | 11:25 |
| piggz | lbt: preopery fixed or held together with tape? | 11:59 |
| lbt | kicked this time... pending an OBS update really | 12:01 |
| lbt | it should happen less as the cache is filled | 12:01 |
| poetaster | (tape, bah! bubble gum and string) | 13:45 |
| poetaster | (or inotifywait!) | 13:45 |
| piggz | lbt: not another update ? :D ... will we have to wait as long as last time | 13:52 |
| poetaster | don't be mean. | 16:15 |
| poetaster | piggz: is there anyting in particular you want'ed tested with 4.3? | 16:16 |
| poetaster | piggz: network still seems off, lipstick screensnaps crash, but anything else? | 16:17 |
| b100dian[m] | thanks rinigus for the unexpected here integration - with routing \o/. | 23:05 |
| b100dian[m] | should that also help people complaining bring back jolla maps | 23:07 |
| b100dian[m] | (haven't been 'round then) | 23:07 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!