[00:01] <tsimonq2> When using Launchpad SSO, what dictates whether 2FA is enabled? What I mean by that is, 2FA is enabled when I log into Launchpad itself, but can I enable that on, for example, a Jenkins instance that uses Launchpad OpenID?
[00:15] <rbasak> tsimonq2: AIUI, 2FA is a property of an Ubuntu SSO account, not the consuming service. That's just from observation - I have no specific engineering knowledge of the setup.
[00:15] <rbasak> OTOH, again from observation, it seems to me that different consuming services have different reauth intervals.
[00:16] <rbasak> I have 2FA enabled (as is required for Canonical employees AIUI) and I've never seen a service not cause SSO to require it in addition to my password.
[00:17] <rbasak> (OTOH if I authenticated to SSO recently, then services tend not to require me to reauth at all)
[00:17] <rbasak> HTH.
[00:38] <wgrant> tsimonq2: Launchpad hasn't been an SSO provider for nearly a decade now; login.launchpad.net is now an alias for Ubuntu SSO. On login.ubuntu.com or login.launchpad.net you'll see a toggle in the "Authentication devices" section to always require 2FA for your account, or only require it when a site requests it.
[01:10] <tsimonq2> Aha, thanks, to both of you. :)
[06:25] <cjwatson> wxl: When it's deployed I'll change the bug status to "Fix Released"
[06:25] <wxl> cjwatson: ok i'll stop being a pest XD
[06:26] <cjwatson> wxl: It's normal that "Fix Committed" means "fix is in revision control somewhere but you probably can't actually use it yet"
[12:27] <rbasak> cjwatson: some launchpadlib advice please?
[12:28] <rbasak> I enabled the debugging you suggested, and noticed that I'm making an absolutely excessive number of calls to "GET /devel/ubuntu/disco" and the like.
[12:28] <rbasak> Once for every publication record that we examine.
[12:28] <rbasak> I think it's time to optimise that out, since it's hampering my efforts to debug the current hang.
[12:29] <rbasak> The reason this is happening is that I iterate through source_package_publishing_history objects, and on each one, I look up the distribution name and the series name.
[12:29] <rbasak> I tried @functools.lru_cache, but since I'm wrapped in a different object every time, it's not deduplicating the lookups for different source_package_publishing_history objects that use the same distribution
[12:30] <rbasak> source_package_publishing_history_obj.distribution.name, etc.
[12:30] <rbasak> Every source_package_publishing_history_obj.distribution lookup gives me a new object (eg. different id()) AFAICT.
[12:31] <rbasak> I understand that str(source_package_publishing_history_obj.distribution) would be the same every time, so I can cache myself (launchpadlib API client side) on that.
[12:31] <rbasak> But it'll be painful to do every relevant call.
[12:31] <rbasak> Is there any better way?
[12:32] <rbasak> IOW, the ease of blindly just doing source_package_publishing_history_obj.distribution.name is hurting me now, and I'm not sure how to make the obvious optimisation in a clean and Pythonic way.
[12:33] <rbasak> (each API call does return with 304 Not Modified, but it's still a ludicrous number of round trips)
[12:52] <cjwatson> rbasak: You probably want something that caches based on the value of distribution_link rather than on str(distribution).  The only precedent I know of is the slightly odd wrapping that ubuntu-dev-tools does.
[12:54] <cjwatson> rbasak: Depending on how many different kinds of objects need to be changed, I might suggest something like an object that wraps source_package_publishing_history and has a distribution_name property that keeps a cache on the class keyed off distribution_link.  Something like that.
[12:54] <cjwatson> Tedious if you need to do that kind of thing to lots of kinds of objects, but OK if it's just a few.
[19:24] <sbeattie> rbasak: hey, do you have a pointer to the debugging you added? I have an lplib script I need to do some optimizing/caching for.