[00:41] wgrant: is there a way to abort a recipe build? [00:41] (we spotted a failure locally, so we would prefer to shut it down before waiting forever) [00:51] ehoover: You should have a cancel link on the build page [00:51] Otherwise I do. [00:51] wgrant: nope: https://code.launchpad.net/~pipelight/+archive/stable/+recipebuild/648715 [00:51] (recipe part of build, not build part of build - if that helps) [00:51] ehoover: Cancelled [00:51] wgrant: thank you so much :) [00:52] np [01:11] 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] ehoover: That's hard to make a general statement about. Have you tried running the recipe locally? [01:19] wgrant: yeah, it takes forever locally too [01:19] Is it network-bound, CPU-bound, RAM-bound? [01:20] wgrant: good question, let me run it again [01:22] (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] wgrant: hmm, i actually got a connection timeout while it was still downloading :/ [01:31] :/ [01:32] wgrant: do you know if there's a quick and easy way to change the timeout? [01:32] Assuming it's the 300 second timeout, there is no way to change it. [01:32] That usually means the connection was idle for a long time [01:33] Suggesting you might be CPU-limited locally, or something like that [01:34] 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] (and yes, it was a 300 second timeout) [01:39] wgrant: none of my cores went over about 10%, my RAM is almost completely free, and iotop reports very little activity [01:39] during where it's working on the "build phase", not long after this message: [01:39] 96288kB 500kB/s - Build phase:Adding file contents 5575/7072 [01:40] it wrote out: [01:40] Connection Timeout: disconnecting client after 300.0 seconds072 [01:41] 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] but it eventually finishes, it just takes a really long time [01:41] It might only work on the build farm because they use HTTP [01:41] So there's no session to time out. [01:42] wgrant: well, i could pre-download the repo and do it that way - if that will help [01:46] ehoover: It's worth a try, I think [01:58] 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] ehoover: Nope, the timeout is at a higher level than that. [01:58] hmm [01:58] It's based on Bazaar smartserver commands, not just SSH activity. [02:05] wgrant: ok, local build is in progress and it's only using one core and pegging - hard [02:07] iotop shows nothing, iftop shows nothing [02:09] still true after "All changes applied successfully.", one core is pegged [02:19] 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] anway, need to head home before the wife gets upset - ttyl === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === zz_mwhudson is now known as zz_zz_mwhudson [12:28] is there an easy way to retrieve the gpg pubkey of everyone with upload rights to main & universe? [12:48] directhex: does the ubuntu keyring include them all? [12:48] jelmer, i don't know. does it? [12:55] could stab wgrant to find out [12:55] not like he actually sleeps ;) [13:29] no, the Ubuntu keyring doesn't, but it should be scriptable using the API. let me see if I can demonstrate that ... [13:35] i'd definitely appreciate such a script, or its output, to jo.shields@collabora.co.uk [13:36] ok, working on it [13:38] thanks === mattw is now known as Guest79334 [13:41] 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] 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] 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] but I can easily annotate them [13:45] 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] k [14:10] 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] https://launchpadlibrarian.net/165391068/buildlog_ubuntu-precise-i386.sleuthkit_4.1.3-1ubuntu4_FAILEDTOBUILD.txt.gz [14:16] ekristen: It's in https://launchpad.net/~pi-rho/+archive/security, which /~sift/+archive/dev is apparently configured to depend on [14:16] ah [14:16] I missed that [14:17] cjwatson: thank you! [14:17] (see https://launchpad.net/~sift/+archive/dev/+edit-dependencies) [14:17] yw [14:19] directhex: ok, yhm [14:20] ta [15:25] 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] 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] though that first error might indeed indicate a missing build-dependency [15:39] (This is not Launchpad-specific; you ought to be able to reproduce the exact same failures in a local sbuild instance.) [15:39] I’m realitively new to launchpad and all, I’ll have to checkout sbuild [15:44] guess getting a local build of sbuild up is a little involved [15:45] https://wiki.ubuntu.com/SimpleSbuild [15:49] thanks [15:52] cjwatson: sg build asks for a password any idea what password it wants? [15:53] your own [15:54] :/ it doesn’t work [15:54] "doesn't work" is not a useful report [15:54] sorry always says “invalid password" [15:54] also it should be "sg sbuild" not "sg build" as you typoed above [15:55] sorry, that was a typo [15:55] on my part [15:55] but you can always just log out and back in to get the new group membership [15:55] hrm that seems to have done the trick, thanks [16:09] 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? [16:09] bug 1164683 in util-linux (Ubuntu Quantal) "libblkid: udf superblock does not read correctly when blocksize < 2048" [Undecided,Confirmed] https://launchpad.net/bugs/1164683 === TheLordOfTime is now known as teward === JoseeAntonioR is now known as jose [22:18] cjwatson: I don’t think https://wiki.ubuntu.com/SimpleSbuild works on precise, at least I can’t get it to work [23:50] 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