[00:01] 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] 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] OTOH, again from observation, it seems to me that different consuming services have different reauth intervals. [00:16] 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] (OTOH if I authenticated to SSO recently, then services tend not to require me to reauth at all) [00:17] HTH. [00:38] 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] Aha, thanks, to both of you. :) === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [06:25] wxl: When it's deployed I'll change the bug status to "Fix Released" [06:25] cjwatson: ok i'll stop being a pest XD [06:26] wxl: It's normal that "Fix Committed" means "fix is in revision control somewhere but you probably can't actually use it yet" === epod is now known as luk3yx === chihchun is now known as chihchun_afk [12:27] cjwatson: some launchpadlib advice please? [12:28] 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] Once for every publication record that we examine. [12:28] I think it's time to optimise that out, since it's hampering my efforts to debug the current hang. [12:29] 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] 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] source_package_publishing_history_obj.distribution.name, etc. [12:30] Every source_package_publishing_history_obj.distribution lookup gives me a new object (eg. different id()) AFAICT. [12:31] 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] But it'll be painful to do every relevant call. [12:31] Is there any better way? [12:32] 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] (each API call does return with 304 Not Modified, but it's still a ludicrous number of round trips) [12:52] 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] 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] Tedious if you need to do that kind of thing to lots of kinds of objects, but OK if it's just a few. === chihchun_afk is now known as chihchun [19:24] 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.