[02:33] <riiot232> hello
=== ricab is now known as ricab|brb
=== ricab|brb is now known as ricab
=== alan_g is now known as alan_g_
=== ricab is now known as ricab|lunch
[14:16] <coreycb> bdmurray: thanks for helping move bug 1809454 along. would you be able to take a look at bionic today?
[14:16] <ubottu> bug 1809454 in OpenStack Compute (nova) queens "[SRU] nova rbd auth fallback uses cinder user with libvirt secret" [Medium,In progress] https://launchpad.net/bugs/1809454
=== ricab|lunch is now known as ricab
[14:39] <cpaelzer> coreycb: is the 18.04.2 freeze lifted already ?
[14:39] <coreycb> cpaelzer: ahh, maybe not.
[15:01] <coreycb> cpaelzer: do you think we can re-evaluate this MIR? https://bugs.launchpad.net/ubuntu/+source/placement/+bug/1805691
[15:01] <ubottu> Launchpad bug 1805691 in placement (Ubuntu) "[MIR] placement" [Undecided,Expired]
[15:02] <coreycb> the security team ACKed it I believe
[15:02] <coreycb> i don't think nova is going to drop their placement support until train (corresponds to Ubuntu E release) but it would be nice if we could move forward with charm changes
[15:16] <cpaelzer> coreycb: yes and done
[15:16] <coreycb> thanks very much cpaelzer
[15:23] <seb128> if some wonder why retracing are failing recently in disco, bug #1815774
[15:23] <ubottu> bug 1815774 in binutils (Ubuntu) "binutils 2.32 update breaks debug symbols in disco" [High,New] https://launchpad.net/bugs/1815774
[15:24] <seb128> doko, ^
[15:44] <riiot232> hello
[15:44] <riiot232> is some one there.....?
[15:47] <LtWorf> riiot232: no :P
[15:48] <riiot232> :l
[15:48] <riiot232> why?
[15:48] <riiot232> where is every one at?
[15:48] <LtWorf> (i was kidding)
[15:48] <riiot232> ok.
[15:48] <riiot232> so are u dev?
[15:48] <LtWorf> anyway i'm more active on debian, which is oftc rather than freenode
[15:49] <riiot232> ok
[15:50] <bdmurray> seb128: How did you find bug 1815774? Were you manually retracing something or looking at logs / failures to retrace?
[15:50] <ubottu> bug 1815774 in binutils (Ubuntu) "binutils 2.32 update breaks debug symbols in disco" [High,New] https://launchpad.net/bugs/1815774
[15:51] <LtWorf> riiot232: very minor contributions in debian, that then end up in ubuntu
[15:51] <seb128> bdmurray, I wondered why we got a few bugs invalidated by the retracers so I decided to try to sigsegv g-c-c locally and see what was the problem
[15:51] <riiot232> LtWorf ok
[15:51] <riiot232> how do I say ur name?
[15:51] <seb128> bdmurray, which gave me the warnings described in the bug, which I google for, found thar arch bug...
[15:52] <bdmurray> seb128: Hmm, I thought I was subscribed to apport-failed-retrace but didn't notice anything. I'll have to dig.
[15:52] <seb128> bdmurray, https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1815703
[15:52] <ubottu> Error: launchpad bug 1815703 not found
[15:52] <seb128> https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1815704
[15:52] <ubottu> Error: launchpad bug 1815704 not found
[15:52] <seb128> if you want some examples
[15:52] <bdmurray> seb128: cool, thanks
[15:53] <seb128> bdmurray, they didn't got tagged apport-failed-retrace it looks like, just untagged
[15:53] <bdmurray> what's up with that ascii art?
[15:53] <seb128> so maybe an apport bug there
[15:53] <seb128> lol, good question :)
[15:53] <bdmurray> ah, well then
[15:54] <bdmurray> wow, pretty colors too
[15:55] <chiluk> So I discovered today that my ubuntu one login has 2fa enabled, but since I'm no longer at Canonical, I'm no longer in the correct groups that tell Ubuntu One I need to see 2fa configuration pages... Seems like we should auto-enroll all members of ex-canonical in sso-2f-testers  *(or maybe some other group)..  The strangest thing was that I was able to log in to ubuntu one using only my user/pass, but when trying to enable
[15:55] <chiluk> livepatch it required my 2fa ..
[15:57] <chiluk> who owns ubuntu sso / one login now?
[15:57] <cjwatson> the snap store team
[15:58] <cjwatson> What you describe is interesting; I've heard people with this problem before but not the specifics about logging into login.u.c directly vs. via something like livepatch
[15:58] <cjwatson> Though it's possibly related to the same kind of thing that caused https://bugs.launchpad.net/canonical-identity-provider/+bug/1073074
[15:58] <ubottu> Launchpad bug 1073074 in Canonical SSO provider "sso prevents login when 2f required but user doesn't have 2F feature available" [High,Confirmed]
[15:59] <chiluk> Cool I'll move conversation to that bug..
[15:59] <cjwatson> I'm not certain it's the same thing, so I'd suggest a new bug
[15:59] <cjwatson> Can always be duped later
[15:59] <chiluk> Yeah I'll proceed with due diligence.
[15:59] <cjwatson> I don't think auto-adding people to a team is the solution
[16:00] <chiluk> I'm not sure what the right answer is either.. nor do I have the power any more.
[16:00] <cjwatson> Well, it seems that if a user is set to require 2FA then we should show them 2FA ...
[16:01] <cjwatson> (which is what I thought the behaviour was, but the difference between direct login and via livepatch suggests maybe not on all code paths)
[16:03] <chiluk> right..
[16:03] <chiluk> also explains why I haven't noticed till now..
[16:05] <cjwatson> chiluk: livepatch via CLI or OpenID?
[16:05] <chiluk> It was via the "Software & Updates" application...  I forget what the actual runtime is for that.
[16:06] <cjwatson> chiluk: OK, worth also trying something that's definitely OpenID, e.g. open a private browser window and try to sign into LP using it
[16:06] <chiluk> although I think I hit this via cli before as well when following the livepatch instructions.
[16:06] <cjwatson> I have to go out shortly though
[16:07] <chiluk> now I'm really confused.. via a private browser it required 2fa..
[16:07] <chiluk> so it could likely be the same issue.
=== alan_g is now known as alan_g_
[16:18] <cjwatson> chiluk: And double-check direct login to login.u.c via a private browser?
[16:20] <chiluk> yeah also requires 2fa..
[16:20] <cjwatson> so I'm not sure what you mean by "I was able to log in to ubuntu one using only my user/pass"
[16:20] <chiluk> I was just added to https://launchpad.net/~sso-2f-testers ... and can now configure the 2fa devices..
[16:20] <cjwatson> oh
[16:20] <cjwatson> in that case all tests after the point when you were added to that team should be flagged as uninteresting for the purpose of this bug
[16:20] <cjwatson> evidence now invalid
[16:20] <chiluk> yeah.
[16:21] <chiluk> I'm not sure when that exactly happened.
[16:21] <cjwatson> LP should have the timestamp
[16:21] <chiluk> right but I dont' have timestamps on my browsers.
[16:21] <cjwatson> ah
[16:22] <cjwatson> well, it happened at 15:53:25
[16:22] <cjwatson> which was a couple of minutes before you asked about it here
[16:22] <cjwatson> so anything you did in response to my questions can't be useful evidence
[16:22] <chiluk> yeah.
[16:22] <cjwatson> oh well
[16:23] <chiluk> cjwatson want to remove me from sso-2f-testers  to retest?
[16:23] <chiluk> does it matter?
[16:23] <chiluk> I'm willing to help out for a few minutes if you are intrigued.
[16:23] <chiluk> I figure you getting removed from canonical might be more prohibitive for testing.
[16:24] <cjwatson> (a) I can't do that since I'm not an admin of sso-2f-testers, (b) we can set up a similar situation with a local SSO deployment, (c) I have to go out
[16:25] <cjwatson> so thanks but we should be able to manage :)
[16:25] <chiluk> sure thing..
[16:25] <chiluk> it's been nice seeing an old-familiar nic...
[16:25] <chiluk> I haven't played here in far too long.
[16:26] <roadmr> chiluk: hey, I enabled your 2fa group membership, so maybe I can help, but give me a few because I'm busy atm
[16:27] <chiluk> yeah my day is pretty busy too..
[16:27] <cjwatson> ah, roadmr is likely in a better position to help with this than I am anyway, excellent
[16:35] <chiluk> roadmr: I described what I was seeing here : https://bugs.launchpad.net/canonical-identity-provider/+bug/1073074    I think the two are probably the same.
[16:35] <ubottu> Launchpad bug 1073074 in Canonical SSO provider "sso prevents login when 2f required but user doesn't have 2F feature available" [High,Confirmed]
[16:37] <roadmr> chiluk: ok, reading the bug now and I checked the backlog as well
[16:41] <roadmr> chiluk: ok so to summarize, as an ex-canonicaler, you saw different 2fa requirements for API (i.e. gnome-software) vs. web (login.ubuntu.com) ?
[16:41] <roadmr> chiluk: the code does have custom logic for how to decide 2fa-ness for someone in canonical vs. someone in ~sso-2f-testers
[16:42] <roadmr> so that's where I'd start looking but it does look like a bug. I'll investigate!
[16:42] <roadmr> chiluk: and to be clear, are things working well for you now?
[16:46] <chiluk> Yeah things are fine now.
[16:46] <chiluk> the weirdest thing is that openid/web login seemed to work fine and did not require 2fa...
[16:47] <roadmr> yes, that's weird
[16:47] <chiluk> and I'm positive of this because I've been using launchpad for years without my yubikey..
[16:47] <chiluk> today I had to go grab my old yubikey that I had previously had linked.
[16:47] <chiluk> all my devices were still configured.
[16:47] <roadmr> chiluk: which email address do you use to log in these days? (you can pm it to me if you don't want to expose it here)
[16:48] <roadmr> this is so I can look you up and check your account setup, so I can then trace how the logic handles your login attempts via api vs. web
[16:48] <chiluk> Including my old @canonical authenticator app. *(I actually wonder if that is a mini security hole)...
[16:49] <chiluk> is there a better channel for this?  no need to spam everyone here.
[17:01] <roaksoax> ~/win 4
[17:20] <sparr> is there an appropriate channel for support-in-investigating-and-filing-a-bug-report in a mainline kernel package?
[17:22] <rbasak> sparr: mainline as in upstream? Or Ubuntu?
[17:22] <rbasak> For Ubuntu, #ubuntu-kernel
[17:29] <sparr> thanks
[17:50] <roaksoax> /win/win 4
=== realitix_ is now known as realitix
[23:05] <seb128> wgrant, cjwatson, hey, can we open disco for translations?
[23:10] <wgrant> seb128: I believe it's just blocked on UTC turning it on
[23:11] <wgrant> Oh, or maybe not
[23:11] <wgrant> Hm
[23:11] <wgrant> Apparently we never initialised it
[23:11] <wgrant> Things are a bit on fire atm, may be able to look later.
[23:13] <seb128> wgrant, no hurry, thx