=== bradb tries a third time to baz get kiko's changes === terrex [~terrex@84-122-73-155.onocable.ono.com] has joined #launchpad [12:11] "Applying 98 revisions"...i can't think of one good reason under the sun of why i should see that when baz get'ing kiko's branch. === terrex [~terrex@84-122-73-155.onocable.ono.com] has joined #launchpad [12:22] What's the problem? [12:23] You doubt that he comitted 98 times? [12:25] ......... [12:25] gzip: stdin: unexpected end of file [12:25] tar: Child returned status 1 [12:25] tar: Error exit delayed from previous errors [12:25] baz: uncaught exception: -1:(arch_get_patch: tar exitted with non-0 status) [12:25] please report this as a bug to bazaar@lists.canonical.com [12:25] jblack: the problem is that it sends a very hostile message to the user. it says "screw you sucker! you ain't goin' ANYWHERE tonight!" [12:26] and now, heck, it appears i can't even get the branch at all === bradb tries getting rf instead [12:30] hm, no, maybe delta instead [12:35] tar exited with non 0.... [12:35] That implies that the archvie is corrupted on the filesystme level [12:36] jblack: dude, do you still working ?!?! [12:36] jblack: whose archive? [12:36] brabd: whichever archive its building the revision for. [12:37] cprov: My flight today was cancelled, so I fly tomorrow instead. [12:37] p.s. i'm now doing: baz delta --diffs $rocketfuel christian.reis@canonical.com--lozenge/launchpad--devel--0 > kikos_changes.patch [12:37] cprov: Got you sweet stuff, btw. [12:37] bradb: Can you tell which revision tar is complaining about? [12:37] jblack: ohh dear ... [12:38] jblack: christian.reis@canonical.com--lozenge/launchpad--devel--0 is my best guess, but i have absolutely no idea if that's the real problem. [12:38] I couldn't get you chocolate (its middle of the summer in the US and it would have melted in the car) but I did get you hard candy. [12:38] bradb: mind giving me the location? I'll try doing a get here. [12:38] jblack: sftp://chinstrap.warthogs.hbd.com/home/warthogs/archives/christian.reis@canonical.com--lozenge [12:39] registering... getting (this will take awhile) [12:39] bah, failed again, i give up [12:40] the bottom of the error message looked like: [12:40] tar: launchpad--devel--0--patch-3.patches/patches/daemons: Cannot mkdir: No such file or directory [12:40] tar: launchpad--devel--0--patch-3.patches/patches/daemons/librarian.tac.patch: Cannot open: No such file or directory [12:40] tar: launchpad--devel--0--patch-3.patches/patches/daemons/trebuchet.tac.patch: Cannot open: No such file or directory [12:40] tar: Error exit delayed from previous errors [12:40] baz: uncaught exception: -1:(arch_get_patch: tar exitted with non-0 status) [12:40] oh, i'm out of space again :/ [12:40] please report this as a bug to bazaar@lists.canonical.com [12:40] Ahhh. [12:40] but i wasn't before [12:40] Running out of disk space would cause that problem. [12:40] (i.e. the previous two times it errored out) [12:40] maybe your archive cache and archive lib are loaded up? [12:41] i've deleted them several times in the last 20 minutes [12:41] personally, I suggest you bite the bullet and get a shiny new 200 gig drive rather than prune, but you're the master of your machine. [12:41] jblack: i suggest the caching be fixed rather than making every user by a baz-sized hard drive. ;) [12:42] s/by a/buy a/ [12:42] How about pruning out extra debs in /var/cache/apt...whatever, /var/log... maybe cutting your pr0n back to the 5 best gigs. [12:42] dude, i had 1,3 GIGS of free space! [12:42] bradb: Yeah. Some code to limit libraries to an arbitrary revision would be nice. [12:43] is your library sparse or nonsparse? [12:43] sparse [12:43] how big is it? [12:43] (that will take some time to check) [12:43] it's empty (again) now [12:44] 2,2G free, here we go again... [12:44] (with the delta command above) [12:44] Do you use , in place of . ? [12:44] So you're saying "2 gigs 200 megs" ? [12:44] i guess so. french thing. [12:44] Ok. Just making sure. [12:45] bradb, this is HILARIOUS [12:45] The library shouldn't be filling 2.2 gigs if you're blanking it and then diffing kiko. [12:45] bradb@oxygen:~ $ baz delta --diffs $rocketfuel christian.reis@canonical.com--lozenge/launchpad--devel--0 > kikos_changes.patch [12:45] It should be the size of 3 or 4 launchpad trees. [12:45] * Scanning for full-tree revision ....................................................................................... done. [12:45] * from archive cached: rocketfuel@canonical.com/launchpad--devel--0--patch-2072 [12:45] * Applying 36 revisions .. [12:45] at this point, "Applying 36 revisions" is BAD NEWS to me. [12:46] bazaar, i *don't* want you to tell me that. i have a lot to do tonight, and it don't include you. [12:46] Are you linux or os-10 ? [12:46] linux, jblack [12:46] ubuntu [12:46] he's been linux for about 10 years now === kiko winks [12:47] I'm not quite sure what to say here... [12:47] You're wiping the libraries that caches revision building, then complaining that they have to be built? [12:47] down to 1,8G... [12:47] (we'll see if this delta goes ok. fourth time might be the charm.) [12:49] btw, if you think baz is bad, you should see git. =) [12:49] How big is your hard drive? === mpool [~mbp@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [12:50] 80G [12:50] bradb, just erase half of that porn and baz will squeal with glee [12:50] home partition is only 9G [12:50] If you don't mind me asking, what's taking up the other 78 gigs? [12:50] i don't want to embarass myself by filling up /usr with a revision library [12:51] can't you just carve something off with lvm? [12:51] bradb, 9G home partition? where do you store all that "source code"? [12:51] You could turn off revision libraries, but performance is going to be bad. [12:51] heh heh [12:52] btw, the reason i only have about 2,2G left is because i like flac [12:52] I don't use revlibs at all ftr [12:52] kiko: ???? You serious? [12:52] * Applying 36 revisions .................................... done. [12:52] * Scanning for full-tree revision ..................................................................................................................................................... done. [12:52] yeah [12:52] * from archive cached: rocketfuel@canonical.com/launchpad--devel--0--patch-1671 [12:52] * Applying 98 revisions ................. [12:52] I don't care for revlibs [12:52] (1.6G and counting now...) [12:53] bradb, if you don't have room for a revision lib, turn it off. [12:53] Ok. done getting kiko. [12:54] jblack: just wondering: is there any particular reason that the speed/cache size issue isn't a developer priority right now? is there something more beneficial to the lp team right now than improving the speed and cache size issues? [12:54] the first time, cold, it took 15 minutes. [12:54] bradb, they are working on imports, don't twist jblack's arm [12:54] there's a lot of booze to import [12:54] sorry, particularly bad baz/pqm week for me [12:55] they got vodka from finland, sake from japan, caipirinhas from the 3rd world [12:55] bradb: The baz team is spending about 90% of its efforts on imports right now. [12:56] The other ten is eaten up by meetings, workflow sync. [12:56] Getting baz with a revlib the second time while hot was 1 min 29 secs [12:56] Getting baz with a revlib, with --link the third time, while hot, was 7.5 seconds. [12:57] i'd love to do --link, if fl-cow were apt-get installable in hoary [12:58] 192.168.99.199/~kiko/launchpad.tar.gz [12:59] jblack: another wierd situation in baz, I've interrupt a commit process at: [12:59] Why's it not in hoary? [12:59] * Creating revlib entry for celso.providelo@canonical.com/launchpad--gpg-ng--0--patch-58 [12:59] ^X [12:59] interrupted commits, hoho [12:59] jblack: since it, baz is lost, no status, nothing usable [12:59] what's broken for you? [01:00] jblack: 5 minutes for a status [01:00] jblack: after this user-crash [01:00] jblack: [01:00] * Applying 98 revisions ........................................................................................... [01:01] gzip: stdin: unexpected end of file [01:01] tar: Child returned status 1 [01:01] tar: Error exit delayed from previous errors [01:01] baz: uncaught exception: -1:(arch_get_patch: tar exitted with non-0 status) [01:01] please report this as a bug to bazaar@lists.canonical.com [01:01] can this possibly be anything to do with DNS or connectivity issues? [01:01] bradb: Didn't we already get to the bottom of it, that your filesystem is too small for a revision library? [01:01] cprov: what was the error? [01:02] jblack: nope, as i already said, it wasn't out of space the first two times it failed. not now either. [01:02] /dev/hda5 9,2G 7,4G 1,4G 85% /home [01:02] jblack: ok, looks like solved, did "baz library-remove launchpad--gpg-ng--0--patch-58" [01:02] bradb: wfm [01:02] cprov: great. =) [01:02] jblack: it rebuild the revlib, and baz archive-mirror sends the stuff [01:02] bradb: could you be running out of space in /tmp as well? [01:02] jblack: thanks [01:03] jblack: nope [01:03] Filesystem Size Used Avail Use% Mounted on [01:03] /dev/hda3 9,2G 4,5G 4,3G 52% / [01:03] tmpfs 252M 0 252M 0% /dev/shm [01:03] /dev/hda5 9,2G 7,4G 1,4G 85% /home [01:03] /dev/hda6 37G 2,2G 33G 7% /usr [01:03] /dev/hda7 9,2G 3,6G 5,2G 42% /var [01:03] none 5,0M 600K 4,5M 12% /dev [01:03] bradb: Would you mind emailing me a long log, from the line where you type in the command, until the line where you're returned to the shell? [01:04] kiko: what's the external IP for that download? :) [01:05] bradb, only the eleet have access to that one :) [01:05] heh [01:05] what does baz gzip ffs [01:05] jblack: sent. it's not actually that long either. [01:06] bradb, just rm -rf something [01:06] and then do it again [01:06] actually [01:06] why don't you merge my tree in? [01:06] third time i've done exactly that! [01:06] oh === cprov waves good night all [01:06] kiko: merging == risk of conflicts [01:06] could your revlibs be foobed [01:06] bradb: For some reason, tar on your system is failing. [01:06] bradb, you don't have a free branch of rocketfuel? [01:06] bradb, I'm synced up with RF [01:06] jblack: can it be a connectivity issue? [01:06] Its not kiko's archive, because I can get it here. [01:06] Maybe its your archive cache. [01:07] maybe you ran out of space and have a partial revision stuck in there [01:07] my archive! the nerve! [01:07] jblack: it's totally empty dude [01:07] Not your arch library. your arch cache [01:07] except for =greedy and =sparse [01:07] oh [01:07] kiko: nope, i could get one though === bradb tries getting rf [01:08] jblack: have you somehow from the error message been able to rule out a connectivity issue? [01:09] rm -rf .arch-cache/archives/christian.reis@canonical.com--lozenge/* [01:10] bradb: Not strictly speaking, no, but it doesn't sound like a conenctivity problem to me, because you can reach some of his stuff. [01:10] I can reach all of his stuff, you can reach all.What sort of connectivity problem would prevent you from hitting a particular .tar.gz file? [01:11] I think what's happened here is that your starved filesystem broke baz at a really unusual time, and you've got something half written somewhere. [01:11] the two places we cache are in a library, if available, and .arch-cache [01:12] right, merging into a fresh rf checkout now. maybe the rm -rf foo did it [01:12] also, baz can sometimes sneak out of its tree looking for a sister tree that works, and use that as an impromptu read-only library (I know, I know) [01:16] jblack: question: why is it merging in 98 revisions when i merge into a fresh rf tree that kiko says he's synched up to? [01:17] sorry, s/merging in/"Applying %d revisions"/ [01:21] bradb: because 98 revisions back is the latest cached revision in the archive. [01:21] baz stores just the changes between revisions normally. [01:21] so, in order to get a full tree, it has to find the most recent full copy of the tree it can get its hands on, then apply the changes for the following revisions, one at a tme [01:23] jblack: when i empty out my revlib, why doesn't isn't it trying to apply 2108 patches to rocketfuel? [01:24] s/doesn't// [01:24] for some reason, i had the impression it was smart enough to do a bit of virtualization [01:24] because somewhere between base-0 and patch-2108, a cached revision was created and stored in the archive. [01:25] That happens by default once every 50 revisions. [01:25] ah [01:26] that you have to build 98 revisions from kiko tells me he's either using an older baz, has disabled cached revisions, or told mirroring to not upload cached revisions. [01:26] or a couple other possibilities [01:26] * from archive cached: rocketfuel@canonical.com/launchpad--devel--0--patch-1671 [01:26] * Applying 98 revisions .................................................................................................. done. [01:27] Read from remote host chinstrap.warthogs.hbd.com: Connection reset by peer [01:27] * Scanning for full-tree revision failed to query archive: [01:27] revision: rocketfuel@canonical.com/launchpad--devel--0--patch-2108 [01:27] location: sftp://chinstrap.warthogs.hbd.com/home/warthogs/archives/rocketfuel@canonical.com [01:27] * Searching for best merge point bradb [01:27] damn dude, i really think there's some connectivity problem action going on here [01:27] That looks like connectivity to me. [01:27] my wireless is flaky sometimes. sometimes it seems like DNS works only 2/3 tries, if that [01:27] I can get on chinstrap with no problem. [01:28] no, the connectivity would be my problem, not chinstrap [01:28] that's what made me lean towards asking about it before though, admittedly, i too wouldn't see a relationship between the gzip failure messages earlier and a connectivity problem. [01:29] Yeah. why break _there_, and consistantly at that? [01:29] more likely it broke at some other time, and wedged something. [01:30] I'm hungry. I don't want to make dishes since I'm leaving tomorrow (again). [01:30] I think I'm going out. === Mez [~Mez@cpc2-lich4-3-0-cust115.brhm.cable.ntl.com] has joined #launchpad [01:41] right, got kiko's changes, diffing now [01:45] wwooo! [01:46] kiko: first thing i might improve: [01:46] class BugWatch(SQLBase): [01:46] + """A watch, which links a Malone bug to a bug in a foreign bugtracker""" [01:46] what about: """A link between an IBug and a bug in an external tracker."? [01:46] er, sorry [01:46] that docstring should also be in the iface, not the content class [01:50] oh...that "Change information for ..." text on the bug edit page is an interesting improvement. [01:54] and he gets rid of the table for also reported in! :) [01:55] kiko: is portlet-bug-people only used on the bug page? (the name implies yes, but just wanted to be sure) [02:00] kiko: this is evil:
    :) [02:24] bradb, now, yes [02:24] it used to be also used in the person page [02:24] sorry [02:25] it used to be also used in the bugtask page [02:25] bradb, yes, it's evil. do you have a suggestion? [02:25] thinking, while finishing off the rest of the review [02:25] I thought of many solutions but none were as simple [02:25] it's a damned hack, agreed [02:25] are you totally against putting the link in a little actions portlet, *just for now*? (since we've already got actions portlet everywhere anyway) [02:26] a one-item actions portlet? :-) [02:27] yeah, that's the problem, hm, /me thinks [02:27] my solution is crude but works :) [02:29] another option i can think of, slightly crude, but somewhat cleaner, is to define a method on BugTaskEditView [02:29] viewingEditScreen, or something [02:29] then tal:condition="view/viewingEditScreen|nothing" (or perhaps a better name for that method) [02:30] that doesn't work [02:30] BugTaskEditView is not the view for tha tportlet [02:30] it makes me feel like crying [02:30] I tried doing that [02:33] oh, ViewWithBugTaskContext, argh, bad memories [02:34] yes [02:34] right [02:40] kiko: response coming along in about 3 mins [02:42] thanks [02:49] time for some dinner [02:51] sent! [02:52] kiko-zzz: ^^^ === bradb heads out, later all [03:00] thanks for putting up with my ranting jblack, hope you have better luck getting to brazil tomorrow ;) === lamont-away is now known as lamont === Mez [~Mez@cpc2-lich4-3-0-cust115.brhm.cable.ntl.com] has joined #launchpad === Mez [~Mez@cpc2-lich4-3-0-cust115.brhm.cable.ntl.com] has joined #launchpad === jdahlin [~jdahlin@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === terrex [~terrex@84-122-73-155.onocable.ono.com] has joined #launchpad === terrex [~terrex@84-122-73-155.onocable.ono.com] has joined #launchpad === spiv [~andrew@fuchsia.puzzling.org] has joined #launchpad === stub [~stub@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === terrex [~terrex@84-122-73-155.onocable.ono.com] has joined #launchpad === terrex [~terrex@84-122-73-155.onocable.ono.com] has joined #launchpad [09:07] Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] Validators should return NULL ON NULL INPUT (patch-2109: stuart.bishop@canonical.com) [09:45] Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial] Refactor database sanity checks to not leave an open connection (patch-2110: stuart.bishop@canonical.com) === SnakeBite [~SnakeBite@84.242.143.64] has joined #launchpad === SnakeBite [~SnakeBite@84.242.143.64] has joined #launchpad === SnakeBite [~SnakeBite@84.242.143.64] has joined #launchpad === palmTree [~chatzilla@213.210.238.40] has joined #launchpad === palmTree [~chatzilla@213.210.238.40] has left #launchpad [] === SnakeBite [~SnakeBite@84.242.143.64] has joined #launchpad [11:19] Merge to rocketfuel@canonical.com/dists--devel--0: [trivial] linkchecker tweaks (patch-97: stuart.bishop@canonical.com) [11:30] Merge to rocketfuel@canonical.com/dists--devel--0: [trivial] Trivial fixes lost in PQM (patch-98: stuart.bishop@canonical.com) [11:31] Merge to rocketfuel@canonical.com/dists--devel--0: [trivial] linkchecker tweaks (patch-99) [11:37] Merge to rocketfuel@canonical.com/dists--devel--0: [trivial] linkchecker tweaks (patch-100: stuart.bishop@canonical.com)