=== chihchun_afk is now known as chihchun === Eickmeyer[m] is now known as eickmeyer[m] === eickmeyer[m] is now known as Eickmeyer[m] === chihchun is now known as chihchun_afk === ricotz_ is now known as ricotz [08:05] cjwatson: to correctly cache my LP objects, I should probably key the cache on the logged in user, to prevent private objects being available to the wrong logins. Unless I assume that there will only ever be one login in the app. Looking for something to key on, I found ._root, which looks like it gives me the top level Launchpad object which should be sufficient. But that's internal. Do you have any [08:06] recommendation on this? === zbr is now known as zbr|rover [08:23] rbasak: I wouldn't cache across logins at all [08:23] rbasak: Why not just make the cache be per-process rather than persistent? [08:24] rbasak: And if you log out (unusual for an API-using program but OK), clear the cache then [08:24] cjwatson: it is per-process and not persistent already. But it's quite deep inside an internal library, so I was concerned that I'd leave a subtle bug in that library unless I key the cache by login [08:27] rbasak: You could probably just key on the hash of the lp object itself. Logging in is done by creating a new instance of that. [08:27] That is, instances of the Launchpad class [08:28] I don't think that would work in this case. [08:29] The problem is that the object is different, which is where my problem is coming from in the first place. [08:29] I am iterating over source_package_publication_history objects [08:29] On each of those, I fetch things like the distro_series attribute [08:29] Each of those is resulting in an API round trip to fetch it (even if it comes back with Not Modified) [08:30] However distro_series_link is the same every time, so that's what I'm keying my cache on (which works) [08:30] I don't see how you can both cache across logins and not cache across logins. [08:30] If the instance of the Launchpad object is different then surely that indicates a fresh login (if perhaps the same user) [08:30] So why is that happening? [08:31] Each source_package_publication_history object is different, as expected, right? [08:31] How do I get to the Launchpad object from that? [08:31] I only found _root [08:31] Which is internal [08:31] Oh I see what you mean [08:31] Meeting, back in 20 minutes or so [08:31] ack [08:47] rbasak: I think using _root is your only option [08:47] It's technically private but in practice very stable [08:57] OK. Thanks! [08:59] FWIW, http://paste.ubuntu.com/p/rYnjwB5557/ is what I have now, which seems to work. [09:03] Looks quite nice [09:05] Thanks! === juliank is now known as juliank|dalek === juliank|dalek is now known as juliank [15:42] hi, afaics there are some ppa builds stuck at "purging the builddir" -- https://launchpad.net/~mozillateam/+archive/ubuntu/firefox-next/+build/16688179 -- most builds are stuck in https://launchpad.net/~mozillateam/+archive/ubuntu/firefox-next/+packages [16:11] cjwatson, hi :), ^ === zbr is now known as zbr|rover [17:08] are ppa builders all busy/taken? [17:19] oh, archive open.. maybe that's why === corvus is now known as jeblair === jeblair is now known as corvus [18:25] cjwatson: hi. is buildd-manager or something like that poorly again? [18:43] I'm not at home right now but I've requested a restart since it's probably that [18:44] ty