| *** frinring_ is now known as frinring | 03:03 | |
| dcaliste | chriadam: hello, I was not able to reproduce the lipstick-security-ui bug yesterday, but lipstick-security-ui was still in the boggus state when I begun my tests. I mean, the process was alive, but it didn't register to any new sailfish-secretsd and any request always ended with "No password agent registered". | 07:14 |
|---|---|---|
| chriadam | dcaliste: if you run sailfish-secretsd manually, then kill lipstick-security-ui (and it should get restarted) does it then reconnect to the sailfish-secretsd? | 07:15 |
| chriadam | I guess you're saying "no, it does not" ? | 07:15 |
| dcaliste | I tried to attach a GDB session to lipstick-security-ui, but GDB complained that the operation was not possible but the /proc/sys/kernel/yama/ptrace entry doesn't exist. | 07:15 |
| chriadam | I wonder if the issue is in the passwordagentplugin (i.e. it should remove the old/stale connection, and allow a new connection from the lipstick-security-ui) | 07:15 |
| dcaliste | Then, I killed lipstick-secrity-ui and then the new one registered properly to the secret daemon and during all day, the bug didn't reappeared… | 07:16 |
| chriadam | whoa | 07:17 |
| chriadam | hrm | 07:17 |
| dcaliste | Yeh, annoying. I cannot exclude that I also restart the secret daemon before checking that it was working. So it's not sure it's an issue with passwordagent plugin. | 07:17 |
| chriadam | so somehow the connection is getting into a stuck state - the lipstick-security-ui exists, but the connection isn't working, and since lipstick-security-ui doesn't get restarted it doesn't recover | 07:18 |
| dcaliste | Exact. | 07:18 |
| dcaliste | But I cannot figure out what steps are required to make the bug appears. I wonder if just stop and restart the sailfish-daemon continuously may lead to it or not… | 07:21 |
| dcaliste | I'm going to add debug messages to the connection / disconnection in passwordagent plugin to try to follow what is happening and exclude (or not) a failure from plugin side. | 07:22 |
| chriadam | sounds like worth trying. I wonder if device suspend might be related also | 07:23 |
| chriadam | sailfish-secrets PR#121 provides a bunch of manual test scripts which could be used to stress-test in case that might trigger | 07:25 |
| chriadam | just run run-matrix-tests.sh in a privileged terminal | 07:25 |
| chriadam | and PR#142 expands those more | 07:26 |
| dcaliste | I see, will try all these approaches indeed to gather more information since the reproduction is somehow difficult to achieve. | 07:27 |
| chriadam | thanks very much! | 07:27 |
| chriadam | I appreciate you doing the legwork to find a repro for this issue. definitely bad if the device can get into a stuck state requiring user to reboot to perform secrets operations :-( | 07:28 |
| dcaliste | Yep, same feeling ;) | 07:28 |
| dcaliste | But now, I know that just lipstick-security-ui need to be killed which is nicer than restarting full lipstick (not a day to day solution though). | 07:29 |
| dcaliste | Besides, looking at passwordagent code, I understand what to put to get double check windows for new password. So it's working now! | 07:31 |
| chriadam | my gut feeling is that we should make lipstick-security-ui a dbus service which kills itself automatically after 10 seconds of inactivity, and which passwordagentplugin is a client of, rather than the other way around.. | 07:31 |
| chriadam | but I need to discuss that with Andrew perhaps, he presumably had good reasons for doing it the current way. | 07:31 |
| chriadam | that's good news :-) | 07:32 |
| dcaliste | (Just a bit annoying (API-wise) that we need to override default repeat message to get the repeat window, as far as I understood.) | 07:32 |
| dcaliste | About the way of client / server, I would agree with you also, but as you said I don't have the full picture. | 07:32 |
| chriadam | I wonder if the default repeat message is simply defined wrongly (and it "should" be the "correct" one), or if that was deliberate to prevent double-check-dialog by default? | 07:34 |
| dcaliste | Well, the dialog switch to CreatePassword state if promptText contains RepeatInstruction, see line 653. But IMHO, it's not possible to set RepeatInstruction with an empty string because of line 208 in interactionparameters.h | 07:37 |
| dcaliste | So to be in the CreateWindow state, one needs to give a string to the repeat instruction, which disable the possibility to use the default one. | 07:38 |
| chriadam | I see. we'd need some placeholder like "default" or something | 07:41 |
| chriadam | then if prompt.value(RepeatInstruction) == "default" then use the actual default one (or set it to empty etc to cause it to be the default one) | 07:41 |
| dcaliste | Yes, and it would be more intuitive from API to have some prompt constructor doing this, like PromptText::PasswordCreationPrompt(). I mean more intuitive than having to provide a specific text with setRepeatInstruction() to get the repeat capability. | 07:45 |
| chriadam | right, I agree | 07:45 |
| chriadam | or some flags to the constructor to specify the behaviour | 07:45 |
| dcaliste | Without reading the code, I just put setNewInstruction("") to do what I wanted. | 07:45 |
| dcaliste | I mean, it's nice to be able to tune every message individually, but it lacks a default job-oriented setter (or constructor). | 07:46 |
| chriadam | yeah. that sort of thing would definitely be nice. I won't have time in the next two weeks to look into making that change, but perhaps after that I can do that. can you create a github issue so I don't forget? | 07:47 |
| dcaliste | At once ;) | 07:47 |
| chriadam | thanks! | 07:48 |
| chriadam | I have to head home now. Good luck with finding the repro for the stuck lipstick-security-ui, let me know what you discover there, and I'll definitely prioritise trying to fix that one as it sounds very serious. | 07:49 |
| chriadam | have a great night :-) | 07:49 |
| dcaliste | Thank you have a safe trip back home. See you. | 07:50 |
| *** Mirv_ is now known as Mirv | 11:33 | |
| *** flx_ is now known as flux | 12:31 | |
| lolek | monich: hi, any news regarding hd voice support? | 13:52 |
| monich | no :/ | 13:52 |
| lolek | monich: not good. Do you think that in the nearest (say a year) future, it will be possible to get it working? | 13:57 |
| monich | lolek: within a year, I would estimate the probability at roughly 30% | 14:00 |
| monich | (don't take this number too seriously) | 14:00 |
| r0kk3rz | generally unless a customer pays for it, it'll get pushed down the priority list | 14:09 |
| lolek | monich: that's very very baad :( | 14:15 |
| lolek | r0kk3rz how much? Maybe community could make some donation for a feature? | 14:15 |
| r0kk3rz | no idea, it would be up to jolla to quote for such work | 14:16 |
| r0kk3rz | which i doubt they will do | 14:16 |
| DennisRoczek | r0kk3rz: yeah, i do want hdvoice. | 14:49 |
| Tekk_ | Why? | 14:59 |
| * Tekk_ didn't even know hd voice was a thing. He just uses voip for most things... | 14:59 | |
| DennisRoczek | because the quality of the simple normal voise calls are much much more better | 15:00 |
| tbr | if that in any way relies on an OS side SIP stack, then: LOLOLOLOLO | 15:03 |
| r0kk3rz[m] | it doesnt | 15:03 |
| *** ced117_ is now known as ced117 | 16:38 | |
| tortoisedoc | yellow | 17:59 |
| tortoisedoc | SfietKonstantinW : how did you get the obs to use rust122 ? | 18:00 |
| tbr | greeeeeeen | 18:00 |
| tortoisedoc | bllllueeeeee | 18:00 |
| tortoisedoc | tbr : do you know about obs? | 18:01 |
| tbr | tortoisedoc: rumor has it that I indeed do | 18:01 |
| tortoisedoc | tbr : im a total obs n00b (huzzah!) and im struggling with getting obs to be able to install built packages; do they need to be separately be deployed after having been published, or does publishing make them available to any build task? | 18:02 |
| tortoisedoc | as in, is publishing the packages enough to use them as dependencies in builds of other rpm packages, or are additional steps required? | 18:05 |
| tbr | as long as they are in the same project, yes | 18:05 |
| tbr | you don't even need to publish them for building against them (only relevant for closed sauce) | 18:06 |
| tortoisedoc | hmm | 18:06 |
| tbr | if they are not in the same project you need to tell your project that it can pull from the other project | 18:07 |
| tortoisedoc | tbr : then there's something else wrong I guess https://build.merproject.org/package/show/home:tortoisedoc:branches:home:sfietkonstantin:sailfish:rust/rust | 18:07 |
| tbr | doesn't rust need a rust build to boostrap itself? | 18:08 |
| tortoisedoc | well apparently not the rustc compiler (cargo & co do) | 18:09 |
| tortoisedoc | rust 1.23 builds out of 1.22, but I cant build 1.24 | 18:09 |
| tortoisedoc | out of 1.23 due to "unavailable" | 18:09 |
| tbr | I only see one rust package | 18:10 |
| tortoisedoc | hmm okay | 18:10 |
| tortoisedoc | I have built only rpm's, made no packages | 18:11 |
| tbr | as in you can't build against yourself | 18:11 |
| tortoisedoc | ah! okay, that explains now | 18:11 |
| tortoisedoc | so I need a new package for each version | 18:11 |
| tbr | or maybe you can, but it's non-trivial (haven't done such stuff) | 18:12 |
| * tortoisedoc goes googling about obs and packages | 18:12 | |
| tbr | so the result of that thing seems to be packages of 1.23 | 18:13 |
| tbr | if you don't want to have a second rust thing, then you'd need to do shenanigans with a bootstrap project | 18:14 |
| tbr | basically a project that provides a rust package until you've built your own rust package | 18:14 |
| tbr | I don't expect that to be very well documented | 18:14 |
| tortoisedoc | its pretty much non-documented yes | 18:15 |
| tortoisedoc | this is all a bit poc | 18:15 |
| tortoisedoc | or actually just playing :) | 18:15 |
| tortoisedoc | i was surprised to find such configure scripts | 18:15 |
| tortoisedoc | in the first place | 18:16 |
| tortoisedoc | and yes I'd definitely avoid a bootstrapper for now at least | 18:16 |
| tbr | tortoisedoc: scroll to the very bottom of the "META" tab https://build.merproject.org/project/meta/mer:core | 18:18 |
| tbr | that's how a bootstrap looks like <path project="mer-core:aarch64:bootstrap" repository="Core_aarch64"/> | 18:18 |
| tortoisedoc | ok thanks | 18:19 |
| tbr | just guessing, but I suspect you could just do the same but with "home:sfietkonstantin:sailfish:rust" and have your local package build 1.24 on top of that. Both packages could retain the name rust and would just differ in versioning | 18:20 |
| tortoisedoc | heh | 18:21 |
| tortoisedoc | rust is a special beast | 18:21 |
| tortoisedoc | 1.22.0 wont build 1.24.0, heck I know how that's possible | 18:21 |
| tortoisedoc | its like a rolling turd | 18:21 |
| tbr | yes, but isn't that package building 1.23? then your package can build on top of that | 18:22 |
| tortoisedoc | yes, that's what I was doing wrong; I was rebuilding 1.24 in the same package | 18:25 |
| tortoisedoc | that built 1.23 | 18:25 |
| tortoisedoc | hah | 18:27 |
| tortoisedoc | funny fact, adding a new package (rust-1.24) nuked my meta info of the rust package | 18:27 |
| tortoisedoc | here be dragons :) | 18:27 |
| tbr | I guess you possibly could engineer it to be one long build process that chains all this and results in packages | 18:30 |
| tbr | it's somewhat inelegant though to every time build 1.23 from 1.22 to then build 1.24 from 1.23 | 18:31 |
| tortoisedoc | indeed | 18:34 |
| tortoisedoc | guess its due to the "infant" nature of rust | 18:35 |
| tortoisedoc | with the complice of "lean" sw development methodologies | 18:35 |
| tortoisedoc | everyone gets left behind, unless they move forward. | 18:36 |
| tortoisedoc | what a beatiful attitude, in 2020 | 18:37 |
| tbr | chooo chooo | 18:44 |
| kimmoli | https://www.youtube.com/watch?v=GnrwM7vFn_U | 19:26 |
| tortoisedoc | kimmoli : Click dat | 19:26 |
| tortoisedoc | b | 19:27 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!