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:41 |
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:51 |
wgrant | np | 00:52 |
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:11 |
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:19 |
ehoover | wgrant: good question, let me run it again | 01:20 |
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:22 |
ehoover | wgrant: hmm, i actually got a connection timeout while it was still downloading :/ | 01:31 |
wgrant | :/ | 01:31 |
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:32 |
wgrant | Suggesting you might be CPU-limited locally, or something like that | 01:33 |
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:34 |
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:39 |
ehoover | it wrote out: | 01:40 |
ehoover | Connection Timeout: disconnecting client after 300.0 seconds072 | 01:40 |
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:41 |
ehoover | wgrant: well, i could pre-download the repo and do it that way - if that will help | 01:42 |
wgrant | ehoover: It's worth a try, I think | 01:46 |
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. | 01:58 |
ehoover | wgrant: ok, local build is in progress and it's only using one core and pegging - hard | 02:05 |
ehoover | iotop shows nothing, iftop shows nothing | 02:07 |
ehoover | still true after "All changes applied successfully.", one core is pegged | 02:09 |
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:19 |
ehoover | anway, need to head home before the wife gets upset - ttyl | 02:27 |
=== Ursinha is now known as Ursinha-afk | ||
=== Ursinha-afk is now known as Ursinha | ||
=== zz_mwhudson is now known as zz_zz_mwhudson | ||
directhex | is there an easy way to retrieve the gpg pubkey of everyone with upload rights to main & universe? | 12:28 |
jelmer | directhex: does the ubuntu keyring include them all? | 12:48 |
directhex | jelmer, i don't know. does it? | 12:48 |
czajkowski | could stab wgrant to find out | 12:55 |
czajkowski | not like he actually sleeps ;) | 12:55 |
cjwatson | no, the Ubuntu keyring doesn't, but it should be scriptable using the API. let me see if I can demonstrate that ... | 13:29 |
directhex | i'd definitely appreciate such a script, or its output, to jo.shields@collabora.co.uk | 13:35 |
cjwatson | ok, working on it | 13:36 |
directhex | thanks | 13:38 |
=== mattw is now known as Guest79334 | ||
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:41 |
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:42 |
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:43 |
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 | 13:45 |
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:10 |
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:16 |
ekristen | cjwatson: thank you! | 14:17 |
cjwatson | (see https://launchpad.net/~sift/+archive/dev/+edit-dependencies) | 14:17 |
cjwatson | yw | 14:17 |
cjwatson | directhex: ok, yhm | 14:19 |
directhex | ta | 14:20 |
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:25 |
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:38 |
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:39 |
ekristen | guess getting a local build of sbuild up is a little involved | 15:44 |
cjwatson | https://wiki.ubuntu.com/SimpleSbuild | 15:45 |
ekristen | thanks | 15:49 |
ekristen | cjwatson: sg build asks for a password any idea what password it wants? | 15:52 |
cjwatson | your own | 15:53 |
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:54 |
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 | 15:55 |
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? | 16:09 |
ubot5 | bug 1164683 in util-linux (Ubuntu Quantal) "libblkid: udf superblock does not read correctly when blocksize < 2048" [Undecided,Confirmed] https://launchpad.net/bugs/1164683 | 16:09 |
=== TheLordOfTime is now known as teward | ||
=== JoseeAntonioR is now known as jose | ||
ekristen | cjwatson: I don’t think https://wiki.ubuntu.com/SimpleSbuild works on precise, at least I can’t get it to work | 22:18 |
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 | 23:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!