[04:07] <shadeslayer> hi, I'm trying to use a private PPA in a pbuilder but I get : W: Failed to fetch https://private-ppa.launchpad.net/kubuntu-ninjas/ppa/ubuntu/dists/saucy/main/binary-amd64/Packages
[04:09] <StevenK> Has that PPA had anything uploaded/copied to saucy?
[04:15] <shadeslayer> yes
[04:16] <shadeslayer> I can access https://private-ppa.launchpad.net/kubuntu-ninjas/ppa/ubuntu/dists/saucy/main/binary-amd64/Packages via the browser just fine
[04:17] <StevenK> shadeslayer: Does your pbuilder use the username and password (that your browser probably remembers)?
[04:17] <shadeslayer> yes
[04:18] <shadeslayer> this is what I have : deb https://rohangarg:myhash@private-ppa.launchpad.net/kubuntu-ninjas/ppa/ubuntu saucy main
[04:18] <shadeslayer> and if I paste https://rohangarg:myhash@private-ppa.launchpad.net/kubuntu-ninjas/ppa/ubuntu into the browser, it works as well
[04:19] <StevenK> And apt-transport-https is installed in the pbuilder?
[04:19] <shadeslayer> yep
[04:20] <StevenK> shadeslayer: There's some debug option involving acquire, let me see
[04:20] <shadeslayer> okay
[04:23] <wgrant> shadeslayer: Try installing ca-certificates
[04:23] <wgrant> In the pbuilder
[04:23] <shadeslayer> ahhh
[04:23] <shadeslayer> that does the trick
[04:23] <shadeslayer> can we get apt-transport-https to recommend that?
[04:25] <wgrant> shadeslayer: infinity was looking at a proper solution last week
[04:25] <wgrant> Not sure what ended up happening
[04:25] <shadeslayer> oh okay
[04:26] <shadeslayer> wgrant: what would  be a more proper solution? :P
[04:26] <wgrant> Probably recommending ca-certificates
[04:26] <wgrant> But not sure yet
[04:31] <shadeslayer> okay
[05:30] <Corey> Howdy.
[05:31] <Corey> Here in .us time, everyone's asleep, any of the .eu folk in early? :-)
[05:31] <Corey> Pushing a package to a PPA, MOST succeeded except for one: https://launchpadlibrarian.net/141529729/buildlog_ubuntu-quantal-i386.salt_0.15.3-1quantal_FAILEDTOBUILD.txt.gz
[05:31] <Corey> That.. looks like a build system error, rather than something code based.
[05:31] <StevenK> It does, yes
[05:32] <Corey> (I have the same thing pushed to four releases, that's the only one that failed).
[05:32] <StevenK> Corey: Link me the build, rather than the log?
[05:32] <Corey> Not sure if that should be reported or ignored.
[05:32] <Corey> StevenK: Sure.
[05:32] <Corey> StevenK: https://launchpad.net/~saltstack/+archive/salt-depends/+build/4637373
[05:33] <Corey> (We build on salt-depends, once that's done we coordinate a multi-platform release by pushing to the stable PPA)
[05:34] <Corey> StevenK: The "retry this build" that I see on that page is how I'd fix this, presumably?
[05:34] <StevenK> Corey: I've already so
[05:35] <Corey> StevenK: Oh, thanks. :-)
[05:35] <StevenK> And the same buildd picked it up, which I was hoping to avoid
[05:35] <wgrant> StevenK: Manual it
[05:35] <Corey> Hmm.
[05:35] <wgrant> It's been failing builds for 8 hours
[05:35] <Corey> StevenK: I'd blame code except that the other three releases completed successfully.
[05:35] <StevenK> wgrant: Manualed
[05:35] <StevenK> Corey: Yes, the builder itself is having a sad.
[05:35] <Corey> Ahh, k.
[05:36] <Corey> For what it's worth, thanks for providing the service. It's appreciated.
[05:36] <Corey> (Just got another failed email)
[05:36]  * StevenK gives it back a second time, glaring at chindi11
[05:36] <Corey> Someone with infra access able to fail that node out of the cluster?
[05:36] <StevenK> Hopefully elnath is having a good day
[05:36] <StevenK> Corey: I've kicked it out already
[05:37] <Corey> Oh, sweet.
[05:39] <Corey> StevenK: You guys ever do a public blog post / talk about how the launchpad build system works under the hood?
[05:40] <StevenK> Lots of duct tape.
[05:40] <Corey> The idea behind it is intriguing. :-)
[05:41] <Corey> (I'm not a developer by any stretch of the imagination, just an ops guy who found there was nobody else to build packages, so I'm more interested in the high level overview.)
[06:44] <lifeless> Corey: its a wrapper for sbuild
[06:44] <lifeless> Corey: with a twisted scheduler and a thin shim for provisioning machines
[09:15] <odony> Hi everyone, how coulw we solve a persistent timeout on the +activereviews page on our trunk branch: https://code.launchpad.net/~openerp/openobject-addons/trunk/+activereviews   /cc wgrant
[09:16] <odony> e.g. oops id OOPS-9f534a33a10ce1f888d0e89f63e268a4
[09:19] <wgrant> odony: You seem to have more than 600 open merges proposed into that branch
[09:19] <wgrant> Is that intentional?
[09:20] <odony> yes and no... we'd like to process that huge backlog, but those open merges are unfortunately valid
[09:21] <wgrant> We're unnecessarily loading the diffstat for each MP diff on that page, which usually isn't a problem, but it might be for some of your branches.
[09:21] <odony> the thing is, trunk accumulates unprocessed merges over the years, while the stable branches are better under control
[09:22] <odony> ah, some of the mp could have incorrect target branches indeed, which could cause overly large diffstats
[09:22] <odony> hard to say which, though
[09:22] <odony> if there are, that should only be the odd case
[09:23] <odony> note that we are able to access the list of merge proposals through the API without timeout, we I'd hate to have to build our own frontend for launchpad ;-)
[09:23] <odony> s/we I'd/I'd/
[09:26] <odony> wgrant: if you have a way to identify a few bad merges in the list I can quickly process them, if there's a chance this can bring the rendering time under the timeout
[09:30] <wgrant> odony: I'm investigating.
[09:32] <wgrant> odony: You have a few MPs with diffstats measuring the megabytes!
[09:32] <wgrant> Oh no, misread
[09:32] <wgrant> Just hundreds of kilobytes
[09:33] <wgrant> So that's possibly not the problem.
[09:34] <odony> wgrant: thanks for taking the time to look into it!
[09:34] <wgrant> https://code.launchpad.net/~credativ/openobject-addons/6.1-lp-1033731/+merge/158120 is fairly impressive
[09:34] <odony> hmm, just the name suggests that it's based on the 6.1 series, so probably a wrong target, let me check
[09:39] <wgrant> https://code.launchpad.net/~openerp/openobject-addons/6.0/+merge/146074 and https://code.launchpad.net/~rr.clearcorp/openobject-addons/6.1-account_asset/+merge/164813 are some other winners
[09:39] <odony> wgrant: indeed, that one was a wrong target, just closed it (1.7 million lines, nice diffstat indeed)
[09:39] <odony> closed it, let me see these orther ones
[09:39] <wgrant> Hopefully getting them off the list will quickly improve that page enough until we fix it properly.
[09:39] <odony> other*
[09:39] <odony> let's try it :-)
[09:45] <odony> wgrant: ok I closed those 3, still getting timeout apparently. Any other with a 6.0-, 6.1- or 7.0- name prefix (or any diff with more than, say, 10k lines) that I could quickly reject?
[09:47] <wgrant> odony: https://code.launchpad.net/~openerp-dev/openobject-addons/7.0-bug-1088833-nco/+merge/144434 is the only other really big one.
[09:48] <odony> wgrant: thanks. BTW we're trying to dedicate a few resources to process all those merges, so hopefully we'll offload trunk soon
[09:51] <odony> wgrant: got rid of that last one as well, but still timing out I think :-(
[09:51]  * wgrant gets a bigger hammer
[09:51]  * odony gets out of the way ;-)
[09:58] <wgrant> odony: smash
[09:58] <wgrant> It should work now
[09:58] <wgrant> Slow, but working
[09:58] <odony> wgrant: woo, thanks a lot!
[09:58] <odony> wgrant: what was that last piece of magic (or ironwork), if I may ask? ;-)
[09:59] <wgrant> I'll file a bug and we can hopefully work out why it's taking so long
[09:59] <wgrant> odony: Um...
[09:59] <wgrant> Increasing the timeout :)
[09:59] <odony> wgrant: oooh I see... is that the global LP timeout or just that of the activereviews page?
[10:00] <wgrant> Just the activereviews page
[10:00] <wgrant> It was previously on the global default
[10:01] <odony> odony: *phew*, I was afraid we had caused the global default to be bumped up
[10:01] <wgrant> Nah, I might not do that so lightly
[10:01] <odony> thought so!
[10:02] <odony> still, we'll get to work right away to process this huge list, thanks so much for you help!
[10:02] <wgrant> Anyway, that page was only designed to show up to a couple of hundred, but it still shouldn't be as slow as it is. Will hopefully work out what's wrong with it in the next couple of weeks and fix it.
[10:03] <odony> wgrant: great, and if you ever need anyone to create a mess of unprocessed thingies on LP (e.g. for stress-testing), just give a call ;-)
[10:03] <wgrant> Haha
[10:10] <wgrant> odony: Bug #1186941
[10:11] <odony> wgrant: thanks again! subscribing to it right now
[10:13] <wgrant> np
[16:11] <ggherdov> Hi all. say I want to know all packages provided by this PPA, and their version: https://launchpad.net/~mercurial-ppa  how to ?
[16:14] <dobey> ggherdov: that's not a ppa, that's a team. and it has several PPAs
[16:15] <dobey> ggherdov: so you'll have to click on the PPA listed on that page that you want more info on. If you want info on all of them at once, you could perhaps use the Launchpad API and write a script to get all the data, but it's probably not all that useful to do so
[16:18] <ggherdov> dobey: ok thanks for the clarification. So, when I did "sudo add-apt-repository ppa:mercurial-ppa/releases" on my system, which one of those PPAs did I add ?
[16:19] <ggherdov> ah releases probably..
[16:19] <ggherdov> and: how to list all packages offered in it ?
[16:24] <ggherdov> ok it must be this https://launchpad.net/~mercurial-ppa/+archive/releases#yui_3_9_1_1_1370276653786_79 sorry for the noise