[10:21] <pjp> Hi, doesn't Launchpad -staging (https://login-lp.staging.ubuntu.com) use the same login credentials as bugs.launchpad.net ?
[10:24] <SpecialK|Canon> pjp: no, staging uses different credentials to production
[10:24] <SpecialK|Canon> Actually sorry, multiple stagings, let me check that
[10:25] <cjwatson> SpecialK|Canon: your first answer was right
[10:26] <SpecialK|Canon> I was thrown by https://help.launchpad.net/StagingServer
[10:26] <cjwatson> qastaging uses production SSO
[10:26] <SpecialK|Canon> But that's because LP syncs, not Ubuntu SSO
[10:26] <cjwatson> Right
[10:27] <pjp> SpecialK|Canon: cjwatson here it says it'll sync over 24 hrs maybe ? -> https://answers.launchpad.net/launchpad/+question/49453
[10:28] <pjp> But that's quite old too
[10:28] <cjwatson> pjp: It may have been true in 2008 but is certainly not true now
[10:29] <pjp> cjwatson: You can't create a new account on staging — instead, create one in Launchpad's production environment and then wait up to 24 hours for your account to be available on staging.
[10:29] <pjp> cjwatson: from https://help.launchpad.net/StagingServer
[10:29] <SpecialK|Canon> pjp: Yeah the StagingServer docs are sort of accurate modulo the auth changes in recent years, I'm trying to come up with some good text
[10:29] <cjwatson> Well
[10:29] <SpecialK|Canon> pjp: your _launchpad account_ will be synced across
[10:30] <cjwatson> staging SSO is sort of synced a little bit and I can never remember the precise details
[10:30] <SpecialK|Canon> pjp: the authentication gubbins used (at some point I will reacquaint myself with openid/oauth specs and use Actual Technical Terms here) aren't
[10:31] <cjwatson> (sorry, I have people talking loudly about baking in the background here, it's v distracting)
[10:31] <pjp> SpecialK|Canon: So -staging needs another account?
[10:31] <cjwatson> What are you actually trying to do?
[10:32] <pjp> cjwatson: I'm trying to write a script to update BZ's on bugs.launchpad.net, but instead of testing it there, I thought testing it on -staging should work. But I can't login to -staging instance.
[10:32] <cjwatson> staging gets very confusing because of the weekly database reset
[10:33] <cjwatson> you may be better off testing on qastaging, which uses production credentials
[10:33] <pjp> cjwatson: ie. -> qastaging.launchpad.net ?
[10:33] <cjwatson> yep
[10:33] <pjp> cjwatson: Okay, cool!
[10:33] <pjp> cjwatson: SpecialK|Canon Thank you.
[10:37] <cjwatson> the confusing thing is that you *can* create an account on staging, but it will vanish the next Saturday when we restore from the latest production dump, which is likely to cause havoc with a corresponding staging SSO account.  We sometimes have to sync up OpenID identifiers manually to make things work properly.  It's very unsatisfactory and we need to revisit the arrangements at some point
[10:37] <SpecialK|Canon> cjwatson: Ah, yes, now I remember the openid syncing
[10:38] <cjwatson> (and there may be errors in the above, I don't totally remember all of it myself and always have to refresh my memory when concrete cases arise)
[10:39] <SpecialK|Canon> cjwatson: I'm inclined to modify HLN to the equivalent of "you [can request an account to] use the staging environment"
[10:40] <cjwatson> I suppose.  Perhaps suggest using qastaging if you don't need a particularly up-to-date production dump
[10:40] <cjwatson> I think we ideally ought to sync production to staging SSO periodically but with different 2FA sequences.  But it interacts in complicated ways with the LP->SSO slony sync of things like team membership information
[10:48] <pjp> cjwatson: SpecialK|Canon When I run script with Launchpad.login_with('LPTest', 'https://qastaging.launchpad.net/'), first it shows a URL to authorise the app to use LP account, I did that. Now when I run the script it throws - HTTP Error 404: Not Found
[10:51] <cjwatson> Can we have more details?
[10:51] <cjwatson> What bit of code or HTTP request or whatever is returning 404?
[10:52] <cjwatson> Launchpad is a large application and there are plenty of legitimate situations where it returns 404, so it isn't possible for us to give advice without more details.
[10:53] <pjp> cjwatson: lp = Launchpad.login_with('LPTest', 'https://qastaging.launchpad.net/')
[10:54] <cjwatson> Oh, I see
[10:54] <cjwatson> Wrong invocation
[10:54] <cjwatson> lp = Launchpad.login_with('LPTest', 'qastaging')
[10:55] <cjwatson> ('https://api.qastaging.launchpad.net/' would also work, but easier to use the alias)
[10:55] <pjp> cjwatson: I see, trying..
[11:03] <pjp> cjwatson: Worked, thank you.
[11:03] <cjwatson> good good
[11:04] <pjp> It was not saving token locally, now it did I guess
[11:47] <xnox> ilasc:  hey, about https://answers.launchpad.net/launchpad/+question/690465
[11:48] <xnox> i don't know if path translation times-out because it is ~xnox who is trying to create the repo and has too many repos, or becuase /ubuntu/ or /+source/linux-signed/
[11:48] <xnox> note that my account times out often on various pages related to ~xnox
[11:49] <xnox> ilasc:  and i don't know how else i can create a repository / fork ubuntu packaging git repo
[11:49]  * xnox is not in ~ubuntu-kernel, so i can't push personal branches there
[11:50] <ilasc> hey xnox , cool, thanks for the info, I'm looking at it now
[11:56] <pjp> Hi, what is bug_target -> https://launchpad.net/+apidoc/devel.html#bug_target, when creating a new bug via lp.bugs.createBug() call ?
[11:59] <cjwatson> xnox's thing probably just needs that repository to be repacked
[12:00] <cjwatson> It's unlikely to have anything to do with their account
[12:00] <cjwatson> pjp: Some kind of container in Launchpad that can have a bug task created targeting it, e.g. a project or a distribution source package
[12:02] <pjp> cjwatson: I tired with target='qemu', target='launchpad' even with URLs like -> https://bugs.qastaging.launchpad.net/qemu, but it throws bad request error
[12:02] <cjwatson> pjp: /qemu rather than qemu
[12:02] <pjp> cjwatson: Oh
[12:04] <pjp> cjwatson: Aha -> https://api.qastaging.launchpad.net/devel/bugs/1742772
[12:04] <pjp> cjwatson: It's not loading CSS for me, but at least I see a test bug
[12:05] <cjwatson> We only just moved qastaging to a different host
[12:05] <cjwatson> So random bits may be broken
[12:05] <cjwatson> That said you shouldn't expect CSS on the API host
[12:05] <cjwatson> Use .web_link if you want something that has CSS
[12:06] <pjp> cjwatson: It's not showing target 'qemu' too
[12:06] <cjwatson> https://bugs.qastaging.launchpad.net/qemu/+bug/1742772
[12:06]  * pjp clicks
[12:07] <cjwatson> bug objects themselves don't have a target; bug task objects do
[12:07] <cjwatson> target= to createBug governs the target of the initial bug task
[12:07] <cjwatson> you can iterate over .bug_Tasks
[12:07] <cjwatson> Er, .bug_tasks
[12:08] <cjwatson> In [1]: lp.bugs[1742772].bug_tasks[0].target
[12:08] <cjwatson> Out[1]: <project at https://api.qastaging.launchpad.net/devel/qemu>
[12:08] <pjp> cjwatson: I see, cool!
[12:18] <ricotz> hello, is there an ETA for the disabled amd64/i386 builders to be back online?
[12:19] <cjwatson> Oh, I hadn't noticed those were down, let me look
[12:19] <ricotz> thanks, the queue is getting a long ;)
[12:19] <ricotz> *bit
[12:24] <cjwatson> Seems to have gone south yesterday for various network reasons, not exactly clear why
[12:24]  * cjwatson enables one to see if it's happy
[12:24] <cjwatson> *now
[12:24] <pjp> cjwatson: Okay, to run it against bugs.launchpad.net, I change 'qastaging' -> 'production' and version='1.0' ?
[12:30] <cjwatson> pjp: Leave version alone
[12:30] <cjwatson> pjp: But 'production', yes
[12:30] <cjwatson> In most cases you want version='devel' unless you know why you don't
[12:30] <pjp> cjwatson: Okay
[12:31] <pjp> cjwatson: Thank you.
[12:43] <cjwatson> ricotz: OK, it's coming back now, thanks
[12:44] <cjwatson> The unit that deals with their resets had OOMed
[13:52] <ricotz> cjwatson, thank you