=== chihchun_afk is now known as chihchun
[07:06] <ePierre> hello!
[07:07] <ePierre> I'm testing a script that interacts with launchpad and before messing up the production database, I would like to test it on staging area
[07:07] <ePierre> I mean staging launchpad
[07:07] <ePierre> in launchpad help page it says: "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."
[07:07] <ePierre> I have an account that was created and activated a long time ago and yet I can't login
[07:09] <ePierre> I see "Incorrect email/password combination" when I try to log with the same info as the one I use on production environment... does anyone know the problem?
[07:16] <ePierre> I have 2 e-mail addresses attached to my launchpad account, but it looks like it fails with both
=== ePierre is now known as ePierre-afk
[17:13] <clivejo> what's going on with LP builders?  15hour long queue for amd64?
[17:15] <nacc> clivejo: there is a infra rebuild going on, meaning limited capacity, and the archive recently opened for bionic, so it's probably loaded
[17:16] <clivejo> why they private builds?
[17:17] <nacc> clivejo: ?
[17:17] <clivejo> Building private job ?
[17:18] <nacc> clivejo: sorry, I'm not sure I understand your question still
[17:18] <clivejo> all the jobs are currently showing as "Building private job" for the amd64 builders
[17:19] <clivejo> or cleaning
[17:19] <nacc> iirc, private jobs get prioritized higher, but i might be wrong
[17:19] <clivejo> just wondering why they are private
[17:24] <cjwatson> Security builds
[17:24] <cjwatson> And yes, the lcy01 cloud is being redeployed at the moment, as part of making it possible to add extra capacity to it
[17:25] <cjwatson> Having these two things happen at the same time is unfortunate, but oh well ...
[17:25] <nacc> cjwatson: it's amazing how quickly people noticed :)
[17:25] <cjwatson> *three, in fact, counting auto-sync
[17:25] <nacc> yeah
[17:25] <nacc> a perfect storm!
[17:25] <cjwatson> Any one of those would have produced a backlog
[17:26] <cjwatson> And yeah, I'm sorry, I can't go into more detail about private builds in public.  Hopefully they'll clear out in an hour or two
[17:32] <cjwatson> a bit over a hundred builds to go in the relevant security queue, I think
[22:40] <Etua> Hello, I need help with creating a new branch for my project. After executing bzr push lp:gnome-paint/stable I get bzr: ERROR: Permission denied: "Cannot create 'stable'. Only Bazaar branches are allowed."
[23:03] <Etua> Could you help me?
[23:12] <wgrant> Etua: A branch needs an owner, so you need to push to lp:~USER_OR_TEAM/gnome-paint/stable
[23:12] <wgrant> lp:gnome-paint/stable is the branch for gnome-paint's "stable" series, which doesn't exist.
[23:14] <nacc> cjwatson: wgrant: I think I'm missing something in the definition of git_target in the launchpad API. I'm working on the repointing script that will, as we import source packages, change the default for a given source package to the imported repository. Is the target somethig like ubuntu/+source/<srcpkg> ?  current script is here: http://paste.ubuntu.com/25868780/. I'm also not sure how to test it. Can I
[23:14] <nacc> unset the default repository to None?
[23:16] <cjwatson> I usually spell it with a leading slash, but yes, a distribution_source_package (whose URL is /ubuntu/+source/<srcpkg>) is an example of a git_target
[23:16] <cjwatson> and the relevant example here
[23:17] <cjwatson> you can unset the default repository for a given target by passing repository=None, yes
[23:17] <nacc> cjwatson: cool, that helps :)
[23:18] <cjwatson> PS you should pass the package names through urllib.parse.quote()
[23:18] <cjwatson> when you're substituting them into URL paths, anyway
[23:18] <nacc> cjwatson: yep, thans as always!
[23:18] <cjwatson> LP will sometimes let you get away without that, but should quote anyway
[23:18] <nacc> yep
[23:26] <nacc> cjwatson: great! thanks again, script works!
[23:42] <nacc> cjwatson: if a source package publishing record does not have a published date, does that typically mean it just hasn't been published yet, but will eventually? e.g. https://api.launchpad.net/devel/ubuntu/+archive/primary/+sourcepub/8444072 and a bunch of the stuff that's stuck right now. I wonder what our script should do for keeping up with the publisher. It seems like we should wait until we start
[23:42] <nacc> seeing published dates again? (we don't want to lose our "place" in the publisher's history)
[23:42] <nacc> rbasak: --^ fyi, there's a bug in my script until we fix that loop :)
[23:44] <cjwatson> correct - date_published is set when the publisher processes a given publishing history entry
[23:44] <cjwatson> it's normal for some recent entries to have date_published=None
[23:45] <nacc> yeah, i think once we've 'caught up', we need to just tread water in our watcher script
[23:45] <nacc> cjwatson: thanks!
[23:50] <wgrant> (date_published is set when the status transitions from Pending to Published)
[23:50] <nacc> wgrant: ah also good
[23:50] <nacc> thanks to you both