[00:41] <ehoover> wgrant: is there a way to abort a recipe build?
[00:41] <ehoover> (we spotted a failure locally, so we would prefer to shut it down before waiting forever)
[00:51] <wgrant> ehoover: You should have a cancel link on the build page
[00:51] <wgrant> Otherwise I do.
[00:51] <ehoover> wgrant: nope: https://code.launchpad.net/~pipelight/+archive/stable/+recipebuild/648715
[00:51] <ehoover> (recipe part of build, not build part of build - if that helps)
[00:51] <wgrant> ehoover: Cancelled
[00:51] <ehoover> wgrant: thank you so much :)
[00:52] <wgrant> np
[01:11] <ehoover> wgrant: is there some reason merging a small repo onto a large repo in a recipe takes a really long time? (and is there a way to work around it?)
[01:19] <wgrant> ehoover: That's hard to make a general statement about. Have you tried running the recipe locally?
[01:19] <ehoover> wgrant: yeah, it takes forever locally too
[01:19] <wgrant> Is it network-bound, CPU-bound, RAM-bound?
[01:20] <ehoover> wgrant: good question, let me run it again
[01:22] <ehoover> (it'll take longer to get to the same point than the build farm since it needs to download everything, but i'll let you know as soon as it's there)
[01:31] <ehoover> wgrant: hmm, i actually got a connection timeout while it was still downloading :/
[01:31] <wgrant> :/
[01:32] <ehoover> wgrant: do you know if there's a quick and easy way to change the timeout?
[01:32] <wgrant> Assuming it's the 300 second timeout, there is no way to change it.
[01:32] <wgrant> That usually means the connection was idle for a long time
[01:33] <wgrant> Suggesting you might be CPU-limited locally, or something like that
[01:34] <ehoover> wgrant: well, it didn't seem to use hardly any of my resources - i have 4 cores with hyperthreading and 16GB of RAM on this box...
[01:34] <ehoover> (and yes, it was a 300 second timeout)
[01:39] <ehoover> wgrant: none of my cores went over about 10%, my RAM is almost completely free, and iotop reports very little activity
[01:39] <ehoover> during where it's working on the "build phase", not long after this message:
[01:39] <ehoover>  96288kB   500kB/s - Build phase:Adding file contents 5575/7072
[01:40] <ehoover> it wrote out:
[01:40] <ehoover> Connection Timeout: disconnecting client after 300.0 seconds072
[01:41] <ehoover> on the build farm it actually hangs after it says "Merging revision 'revno:55' of 'lp:wine-compholio' in to..." and again after "All changes applied successfully."
[01:41] <ehoover> but it eventually finishes, it just takes a really long time
[01:41] <wgrant> It might only work on the build farm because they use HTTP
[01:41] <wgrant> So there's no session to time out.
[01:42] <ehoover> wgrant: well, i could pre-download the repo and do it that way - if that will help
[01:46] <wgrant> ehoover: It's worth a try, I think
[01:58] <ehoover> wgrant: it looks like the connection is over SSH, so (if someone asks in the future) you can probably get it to not timeout by setting the SSH ClientAliveInterval
[01:58] <wgrant> ehoover: Nope, the timeout is at a higher level than that.
[01:58] <ehoover> hmm
[01:58] <wgrant> It's based on Bazaar smartserver commands, not just SSH activity.
[02:05] <ehoover> wgrant: ok, local build is in progress and it's only using one core and pegging - hard
[02:07] <ehoover> iotop shows nothing, iftop shows nothing
[02:09] <ehoover> still true after "All changes applied successfully.", one core is pegged
[02:19] <ehoover> wgrant: where it spends most of the time is between "All changes applied successfully." and "Committing to: ...".  if i spend some time investigating this is there any chance it can get fixed?
[02:27] <ehoover> anway, need to head home before the wife gets upset - ttyl
[12:28] <directhex> is there an easy way to retrieve the gpg pubkey of everyone with upload rights to main & universe?
[12:48] <jelmer> directhex: does the ubuntu keyring include them all?
[12:48] <directhex> jelmer, i don't know. does it?
[12:55] <czajkowski> could stab wgrant to find out
[12:55] <czajkowski> not like he actually sleeps ;)
[13:29] <cjwatson> no, the Ubuntu keyring doesn't, but it should be scriptable using the API.  let me see if I can demonstrate that ...
[13:35] <directhex> i'd definitely appreciate such a script, or its output, to jo.shields@collabora.co.uk
[13:36] <cjwatson> ok, working on it
[13:38] <directhex> thanks
[13:41] <cjwatson> directhex: clarification before I get too far into this: do you mean strictly people who have general upload access to an entire component (core-devs, MOTUs), or also people who have any kind of individual-package or set-of-packages upload access (which I suppose is sort of analogous to DMs)?
[13:42] <directhex> cjwatson, i guess what i want is the ubuntu-flavoured equivalent to the DD and DM keyrings. so whether that means, say, members of core-dev and motu... i haven't kept up to date on how upload rights are delegated these days
[13:43] <cjwatson> I think that is probably equivalent to including per-package upload rights, since DM ~= you get to upload some small number of signed-off packages
[13:43] <cjwatson> but I can easily annotate them
[13:45] <directhex> i'll trust your judgement on this. i wouldn't bother with annotation, i'm just going to munge everything into one big local keyring, because reasons
[13:45] <cjwatson> k
[14:10] <ekristen> morning, I have a package that is failing to build, it depends on a specific version of another package in my PPA, however it continues to fail saying the libewf-dev depends on libewf2-dev, which isn’t true, in fact I cannot find a libewf-dev package out there that does depend on libewf2-dev so I don’t know where it is getting it from, can someone help please —
[14:10] <ekristen> https://launchpadlibrarian.net/165391068/buildlog_ubuntu-precise-i386.sleuthkit_4.1.3-1ubuntu4_FAILEDTOBUILD.txt.gz
[14:16] <cjwatson> ekristen: It's in https://launchpad.net/~pi-rho/+archive/security, which /~sift/+archive/dev is apparently configured to depend on
[14:16] <ekristen> ah
[14:16] <ekristen> I missed that
[14:17] <ekristen> cjwatson: thank you!
[14:17] <cjwatson> (see https://launchpad.net/~sift/+archive/dev/+edit-dependencies)
[14:17] <cjwatson> yw
[14:19] <cjwatson> directhex: ok, yhm
[14:20] <directhex> ta
[15:25] <ekristen> cjwatson: this this package unable to build because of the “cannot find -ltalloc” error? https://launchpadlibrarian.net/165394185/buildlog_ubuntu-precise-i386.pytsk_4.1.3-1ubuntu1_FAILEDTOBUILD.txt.gz
[15:38] <cjwatson> ekristen: no, "tsk3.c:79:29: error: 'TSK_IMG_TYPE_EXTERNAL' undeclared (first use in this function)" and "tsk3.c:141:29: error: 'TSK_IMG_TYPE_EXTERNAL' undeclared (first use in this function)"
[15:38] <cjwatson> though that first error might indeed indicate a missing build-dependency
[15:39] <cjwatson> (This is not Launchpad-specific; you ought to be able to reproduce the exact same failures in a local sbuild instance.)
[15:39] <ekristen> I’m realitively new to launchpad and all, I’ll have to checkout sbuild
[15:44] <ekristen> guess getting a local build of sbuild up is a little involved
[15:45] <cjwatson> https://wiki.ubuntu.com/SimpleSbuild
[15:49] <ekristen> thanks
[15:52] <ekristen> cjwatson: sg build asks for a password any idea what password it wants?
[15:53] <cjwatson> your own
[15:54] <ekristen> :/ it doesn’t work
[15:54] <cjwatson> "doesn't work" is not a useful report
[15:54] <ekristen> sorry always says “invalid password"
[15:54] <cjwatson> also it should be "sg sbuild" not "sg build" as you typoed above
[15:55] <ekristen> sorry, that was a typo
[15:55] <ekristen> on my part
[15:55] <cjwatson> but you can always just log out and back in to get the new group membership
[15:55] <ekristen> hrm that seems to have done the trick, thanks
[16:09] <psusi> bug #1164683 has a remote bug tracker for debian that is incorrectly showing up as the upstream project.  Under target -> distribution it does not give the option to select Debian.  What happened to that choice?
[22:18] <ekristen> cjwatson: I don’t think https://wiki.ubuntu.com/SimpleSbuild works on precise, at least I can’t get it to work
[23:50] <maxb> ekristen: That seems entirely likely, sbuild has improved a fair bit over the last few release cycles. Generally people doing package dev would be using at least the latest stable as a host OS, so instructions tend to target that